+1, some great contributions!
Thanks
On 8 May 2017 at 19:11, Kwasniewska, Alicja
wrote:
> +1 Congrats☺
>
> Regards,
> Alicja Kwasniewska
>
>
>
> *From: *"Vikram Hosakote (vhosakot)"
> *Reply-To: *"OpenStack Development Mailing List (not for
+1, some great contributions. Looking forward to having Duong on the team.
--
Kind Regards,
Dave Walker
On 15 March 2017 at 19:52, Vikram Hosakote (vhosakot) <vhosa...@cisco.com>
wrote:
> +1 Great job Duong!
>
>
>
> Regards,
>
> Vikram Hosakote
>
> IRC:
ins/keystone.$DOMAIN.conf in
> order to be pushed to the relevant containers ?
> --
>
>
> *Christian Tardif*christian.tar...@servinfo.ca
>
> SVP, pensez à l’environnement avant d’imprimer ce message.
>
>
>
> -- Message d'origine --
> De:
= keystone.identity.backends.ldap.Identity
[assignment]
driver = keystone.assignment.backends.sql.Assignment
--
Kind Regards,
Dave Walker
On 1 February 2017 at 05:03, Christian Tardif <christian.tar...@servinfo.ca>
wrote:
> Hi,
>
> I'm looking for domains support in Kolla. I've searched, but didn't find
>
On 29 November 2016 at 16:21, Michał Jastrzębski wrote:
> Hello team!
>
> I'd like to propose to add zhubingbing to kolla (and kolla-ansible)
> core teams. He did great job reviewing code during last couple of
> months.
>
> Consider this proposal +1 from me, voting will be open
Hey Steve,
All of the credential generation is optional right? I mean, as far as
kolla is concerned - it doesn't *need* to generate the passwords... If
/etc/kolla/passwords.yml is created outside of kolla-genpwd, then kolla
isn't creating any credentials itself and the algorithm, entropy and
bjections?
>
> Out of curiosity, are there specific areas of concern in existing
> projects here? Most projects have dropped XML API support.
>
>
Outbound XML datasources which are parsed still used with at least nova
vmware support and multiple cinder drivers.
openstack/ec2-
c284b6d3bf6562763db2cb8a7351 . Click
the clock symbol, and set an hourly interval.
This will mean that all [Security] tagged mails receive an OSSP gmail label.
HTH, let me know if it does.
--
Kind Regards,
Dave Walker
the Election Officials, as soon as possible
after the nomination period has expired.
2. The Technical Committee can appoint a leader to any programs in this
situation, by mutual agreement of the Technical Committee and the p
isn't because of lack of community engagement or
interest IMO.
So.. other than someone failing to nominate for PTL in the time-frame, what
else justifies the statement of "points[ing] to a real disconnect between
those teams and the rest of the community".. or shows that OSSG no lon
te fedora support
>
> [0] http://lists.openstack.org/pipermail/openstack-dev/2016-
> June/098526.html
>
>
>
+1
Honestly, only CentOS and Ubuntu are seriously implemented.. I'd go further
and rip out the rest unl
Option C
Thanks
On 15 September 2016 at 12:10, Ryan Hallisey wrote:
> Option c.
>
> - Ryan
>
> > On Sep 15, 2016, at 4:33 AM, Paul Bourke wrote:
> >
> > c) Split the repository shortly after tagging 3.0.0 – creating a
> kolla-ansible
w Kolla tests to pass. Providing
this, or similar lands - then it is entirely appropriate to blacklist
graphviz===0.5.0 and pick up the fix in the next release of Graphviz.
Thanks
[0]
http://logs.openstack.org/16/367416/1/gate/gate-kolla-python34/64dd4ae/console.html#_2016-09-09_04_
+1
Great stuff Christian
On 8 September 2016 at 03:59, Steven Dake (stdake) wrote:
> Kolla core reviewer team,
>
>
>
> It is my pleasure to nominate Christian Berendt for the Kolla core team.
>
>
>
> Christian’s output over the last cycle has been fantastic – cracking the
>
tain one-line style "Add this $feature" bug
description. It just burns through Launchpad bug numbers, and will likely
never be looked at again.
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not
Regards,
Dave Walker
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
net/tempest/+bug/1536251
These sorts of issues aren't just theoretical and following policy for the
sake of it.. Glance had 3 x areas where 200 responses that also included a
Location header (against RFC-2616 §14.30) which totally broke glance when
deployed behind apache+fcgid+flup (th
r binary support can be
resolved. This has the benefit of 'best-effort' towards binary, with a
clear intent to move across. It also allows more testing of the binary
parts that are present, with just the source parts as required. (this is my
favourite)
--
Kind Regards,
Dave Walker
On 26 July 20
for
kolla-stable-maint.
--
Kind Regards,
Dave Walker
On 22 July 2016 at 10:47, Kwasniewska, Alicja <alicja.kwasniew...@intel.com>
wrote:
> +1 too
>
>
>
> *From:* Mauricio Lima [mailto:mauricioli...@gmail.com]
> *Sent:* Tuesday, July 19, 2016 5:29 PM
>
> *To:* Open
So, this is one of the areas i'm currently on with the Sensu work. I've
been experimenting with a privileged container, which is very similar to
our current kolla_toolbox container.
The agent certainly needs to be in it's own container, with access to be
able to run commands in other namespaces
, but would require about
a day of cleaning up for submission... but if your work can achieve the
objectives above, i'm happy to discontinue... or help make your stack
pluggable.
[0] https://blueprints.launchpad.net/kolla/+spec/sensu
--
Kind Regards,
Dave Walker
On 24 July 2016 at 11:56, Mathias
a at a
Grafana stack (aiui).. but I fear that is too much to achieve this cycle.
--
Kind Regards,
Dave Walker
On 23 July 2016 at 00:11, Fox, Kevin M <kevin@pnnl.gov> wrote:
> I think those are two different, complementary things.
>
> One's metrics and the other is monitoring. Y
l kolla and kolla-ansible have common ancestry? As in, will
they both be based on current Master with irrelevant files removed from
each tree?
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not for us
the horizon docker image larger and more complicated.
What are your thoughts?
[0]
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List
Dockerfile.j2) and seeing if this is still an
issue. A bunch of Centos Binary improvements were made this current cycle
to make more use of yum packages[0].
[0]
https://github.com/openstack/kolla/commit/a8f3da204e6d6ae42b30c166d436
; Doug
Rather that blanket expiring old bugs, it might seem better to expire bugs
which are in non-triaged state which haven't had activity for >18 months.
This would seem like a less aggressive approach to closing issues which
ha
be ported to other teams and was
hosted within openstack-infra and using standard tooling.
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.ope
want a review from neutron-core.
However, this hasn't been forthcoming. I really need this asap, or we will
have to release without it.
Ps. apologies for the empty reply just now.
--
Kind Regards,
Dave Walker
__
OpenS
On 4 May 2016 at 17:55, Sukhdev Kapur wrote:
> Hi Stable Maintainers,
>
> We have a critical bug impacting customers production network. This is a
> minor fix.
> I would like to request an exception so that the customers do not have to
> baby
> sit this patch.
>
>
.
Any questions, please reply here or #openstack-stable
[0] https://review.openstack.org/#/q/status:open+branch:stable/kilo
Thanks
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not for usage questions
the meeting log to be certain, but I'd also continue
them if the mood has now changed.
--
Kind Regards,
Dave Walker
On 11 Apr 2016 16:06, "Clark, Robert Graham" <robert.cl...@hpe.com> wrote:
>
> Thanks Matt, Michael,
>
>
>
> To start with, lets look quickly at the
On 18 Mar 2016 20:11, "Matt Riedemann" <mrie...@linux.vnet.ibm.com> wrote:
>
> I'd like to propose tonyb for stable-maint-core.
> Please respond with ack/nack.
+1, Great work Tony.
--
Kind Regards,
Dave Walker
___
it.
>
>
I found this to be pretty effective with a friendly upstream. Last summer
I pushed a change to their upstream to have OpenStack gerrit included in
the default app and it was warmly received I used to use this app' quite a
b
able. This is yet another reason why directly applying tags
should burn.
Thanks
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...
and convenient, but it's there
> to serve us and so we shouldn't be slaves to it.
Unless anyone else objects, I'd be really happy if you are willing to
scp a handrolled tarball.
I'm happy to help validate it's pristine-state locally here.
Thanks Jeremy!
--
Kind Regards,
Dave Walker
___
a tarball generated outside of Jenkins.
- Skip ceilometer for this release.
Any other ideas?
Thanks
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack
On 15 January 2016 at 10:01, Thierry Carrez <thie...@openstack.org> wrote:
> Ihar Hrachyshka wrote:
>>
>> +1. CVE fixes obviously should be granted an exception.
>
>
> +1
>
Agreed, I have already +2'd on Gerrit. Can another core please do the same?
Tha
questions please direct them to this thread or ping me
(Daviey) on #openstack-stable.
Thanks
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
n pretty bad with discussion and engaging with
fellow stable-maint members, so a standing (short) meeting might help
improve this.
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not for usage questions)
Un
still == version 1, but without a centralised reference
marker it will be version 2.
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
treating each commit as a release AND we
benefit from not needing hacky tooling to fake this.
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
] https://wiki.openstack.org/wiki/DepFreeze
[1] https://wiki.openstack.org/wiki/FeatureFreeze
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
to solve for the times when
backported security fixes slip in without an OSSA header in the
commit message.
Maybe this is a perfect use-case for git-notes? This means the commit
itself isn't touched and the non-scale git-tag space isn't wasted?
--
Kind Regards,
Dave Walker
on Federation rather than extending interaction at other levels.
You may fine the thread of interest:
http://lists.openstack.org/pipermail/openstack-dev/2014-October/048639.html
Thanks
--
Kind Regards,
Dave Walker
__
OpenStack
On 24 July 2015 at 15:26, Boris Bobrov bbob...@mirantis.com wrote:
On Friday 24 July 2015 09:29:32 Dave Walker wrote:
On 24 July 2015 at 05:00, Julian Edwards bigjo...@gmail.com wrote:
Tl;DR is that the *User* management can come from LDAP via the
Identity driver, but the Project/Tenants
.
If i'm re-added, i'll gladly help more with reviews.
Thanks
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
, openstack/anchor went to ldap3 last week
uneventfully, to achieve py3 support.
There is a pending global-requirements change to bring it into there.
Thanks
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List
'!' in the upstream version.
[0]
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
On 13 July 2015 at 21:58, Ian Cordasco ian.corda...@rackspace.com wrote:
On 7/13/15, 15:09, Dave Walker em...@daviey.com wrote:
SNIP
Therefore, these distro's would need to increment the distro epoch if the
upstream version (without the upstream epoch) is lower than the version
currently
://wiki.openstack.org/wiki/Documentation/Conventions#Service_and_project_names
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
the current process?
Long term, we'll benefit from this on stable/liberty - but defining a
process for the old world is probably useful.
Thanks
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not for usage
this for bandit usage,
and potentially other projects?
[0] https://wiki.openstack.org/wiki/Security/Projects/Bandit
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack
.
As Jeremy points out, I fail to see why fallback default behaviour
cannot be used.. Attempt to use version discovery feature, if fail -
fall back to legacy behaviour..
What are the issues associated with this?
Thanks
--
Kind Regards,
Dave Walker
that removes the
core dump bug soon, I will support moving fully to 3.5 or another test
platform, because that bug is causing us trouble in Oslo still.
s/Canonical/ubuntu
Can you link to the bug? I did a quick search, but couldn't find it quickly.
--
Kind Regards,
Dave Walker
points out, the test coverage mandates that we do this.. which
nicely helps us provide some assurance that the branch is constantly
releasable.
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not for usage
, so I dropped it on the floor. If you wanted to work
on a jenkins job to provide advise on proposed changesets, I am sure
the infra' team would be supportive.
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List
method) or uscan and then
diff the tarballs with the one included on the upload and the one
generated. Timestamps (or even shasums) haven't been an important
issue for me, but the actual content and verifiable source is what has
mattered more.
--
Kind Regards,
Dave Walker
On 10 June 2015 at 15:12, Thomas Goirand z...@debian.org wrote:
On 06/10/2015 12:25 PM, Dave Walker wrote:
The initial core reviewers was seeded by representatives of distro's and
vendors to get their input on viability in distro's.
Really? James, were you made core on the requirements?
I
see there is only notices in Known Issues and Limitations
section of low impact. I do not believe we've ever required ordering
in the updates of these, as they are supposed to be pretty
conservative changes that shouldn't enforce limitations like that.
HTH
--
Kind Regards,
Dave Walker
to rebase using git.
Perhaps tags ARE superior for this?
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
in the future.
Thanks
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman
is an example of how it presents it
http://changelogs.ubuntu.com/changelogs/pool/main/n/nova/nova_2014.2.3-0ubuntu1/changelog
Let me know if you want a hand with it, as it should be pretty
portable to other distros quite easily.
Thanks
--
Kind Regards,
Dave Walker
Responses inline.
On 29 May 2015 6:15 pm, Haïkel hgue...@fedoraproject.org wrote:
2015-05-29 15:41 GMT+02:00 Thierry Carrez thie...@openstack.org:
Hi everyone,
TL;DR:
- We propose to stop tagging coordinated point releases (like 2015.1.1)
- We continue maintaining stable branches as a
,
Dave Walker
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
each release keep support
for pbr's major and minor?
(PS. I really like PBR)
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org
Hi,
Recently I have been curious as to which Cinder drivers support
authentication. It seems that only a subset do. I wondered, is this
something that would be useful on the CinderSupportMatrix wiki page?
Thanks
--
Kind Regards,
Dave Walker
to install)
else:
_setup(**attrs)
setup = new_setup
setup(name='foobar',
version='1.0',
description='Foobar',
)
--
Kind Regards,
Dave Walker
On 25 April 2015 at 15:27, Monty Taylor mord...@inaugust.com wrote:
On 04/25/2015 09:49 AM, Jeremy Stanley wrote
Regards,
Dave Walker
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
+2
Flavio seems to have a good understanding of stable branch and has a
good history of reviews.
Thanks.
On 6 January 2015 at 19:32, Adam Gandelman ad...@ubuntu.com wrote:
Hiya-
Flavio has been actively involved in stable branch maintenance for as long
as I can remember, but it looks like
if this generic ringbuffer kernel support was
proposed to mainline kernel?
--
Kind Regards,
Dave Walker
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
:)
--
Kind Regards,
Dave Walker
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
branches is totally
inappropriate.
This causes the effect of both distros and deployers requiring a
higher version which they have not planned for. If we pin
oslo.messaging (which is what we started agreeing in Paris), this
problems goes away.
--
Kind Regards,
Dave Walker
On 15 November 2014 20:23, Robert Collins robe...@robertcollins.net wrote:
On 16 November 2014 09:03, Dave Walker em...@daviey.com wrote:
On 15 November 2014 19:51, Robert Collins robe...@robertcollins.net wrote:
It probably needs to be backed out of stable/icehouse. The issue is
that we were
On 15 November 2014 21:22, Jeremy Stanley fu...@yuggoth.org wrote:
On 2014-11-15 20:38:02 + (+), Dave Walker wrote:
You are right, I accidently folded two issues into 1. However, I do
not understand how we can resolve this issue the way you have outlined
without introducing a new
discussed this.
What do others think?
Thanks
[0] https://review.openstack.org/#/c/131987/
--
Kind Regards,
Dave Walker
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
this information.
Thanks
--
Kind Regards,
Dave Walker
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Hi,
Currently we have two ways of doing Identity Auth backends, these are
sql and ldap.
The SQL backend is the default and is for situations where Keyston is
the canonical Identity provider with username / password being
directly compared to the Keystone database.
LDAP is the current option if
rather explore adding more support for additional federation
protocols/standards, rather than making our own third backend.
Steve
Dave Walker em...@daviey.com wrote on 10/16/2014 02:15:07 PM:
From: Dave Walker em...@daviey.com
To: OpenStack Development Mailing List
openstack-dev
On 16 October 2014 20:07, David Stanek dsta...@dstanek.com wrote:
SNIP
I may be missing something, but can you use the external auth method with
the LDAP backend?
No, as the purpose of the LDAP backend is to validate user/pass
combination are valid. With the external auth plugin, these are
,
Dave Walker
On 16 October 2014 19:58, David Chadwick d.w.chadw...@kent.ac.uk wrote:
Dave
when federation is used, the user's group is stored in a mapping rule.
So we do have a mechanism for storing group memberships without using
LDAP or creating an entry for the user in the SQL backend
we are all agreed we /need/ something. Let's talk about 'what' and
'how', rather than 'if'.
[I will look to be more involved with stable this cycle.]
--
Kind Regards,
Dave Walker
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http
the stack into libvirt seems
like the correct solution?
[0] http://lists.openstack.org/pipermail/openstack-dev/2014-February/027394.html
[1] https://bugs.launchpad.net/nova/+bug/1246201
--
Kind Regards,
Dave Walker
___
OpenStack-dev mailing list
to follow the redirect loop continually. As you can
imagine, the stealthy changing was a real oddity to debug.
More details are here:
https://bugs.launchpad.net/glance/+bug/1299095
Standardisation with standards helps avoid non-standard behaviour. :)
--
Kind Regards,
Dave Walker
On 2 July 2014 03:48
83 matches
Mail list logo