+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 usage
> questions)"
> *Date: *Monday, May 8, 2017 at
+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)
wrote:
> +1 Great job Duong!
>
>
>
> Regards,
>
> Vikram Hosakote
>
> IRC: vhosakot
>
>
>
>
pushed to the relevant containers ?
> --
>
>
> *Christian Tardif*christian.tar...@servinfo.ca
>
> SVP, pensez à l’environnement avant d’imprimer ce message.
>
>
>
> -- Message d'origine --
> De: "Dave Walker"
> À:
river = 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
wrote:
> Hi,
>
> I'm looking for domains support in Kolla. I've searched, but didn't find
> anything relevan
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 for 1 week
> (unti
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 poli
uriosity, 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-api is
d3bf6562763db2cb8a7351 . 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
__
Ope
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 proposed
appointee.
3. The appointed leader has all the same obligations and
responsibilities as a self-
'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 long
;
> [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 unless there is a strong effort from people committed
to getting parity.
--
Kind Regards,
Dave
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 deliverable for Ocata.
> >
> >> On 15/09/16 07:12, Ste
oes allow 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
+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
> top 10 reviewer list
"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 for usage que
s
--
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/listinfo/openstack-dev
mpest/+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 ap
s bug is closed, proper 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
to the ring for
kolla-stable-maint.
--
Kind Regards,
Dave Walker
On 22 July 2016 at 10:47, Kwasniewska, Alicja
wrote:
> +1 too
>
>
>
> *From:* Mauricio Lima [mailto:mauricioli...@gmail.com]
> *Sent:* Tuesday, July 19, 2016 5:29 PM
>
> *To:* OpenStack Developmen
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 /
this working locally, 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 Ju
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 wrote:
> I think those are two different, complementary things.
>
> One's metrics and the other is monitoring. You probably want b
nd 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 usage questions)
s
will make 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 Ma
s 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/a8f3da204e6d6ae42b30c166d436d74064394a1b
--
Kind Regards,
Dave Walker
gs, 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
haven't managed to reach triaged state and are otherwise stale.
This information is available in t
eams 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.openstack.org?s
m 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
__
OpenStack Development Ma
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.
>
> https://review.openstack.org/#/c
.4 on Monday 9th May.
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
ll out 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" wrote:
>
> Thanks Matt, Michael,
>
>
>
> To start with, lets look quickly at the more recen
On 18 Mar 2016 20:11, "Matt Riedemann" wrote:
>
> I'd like to propose tonyb for stable-maint-core.
> Please respond with ack/nack.
+1, Great work Tony.
--
Kind Regards,
Dave Walker
__
OpenStack
gt;
>
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
bit when commuting. Would recommend.
--
Kind Regards,
Dave W
ngs more consistent 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
t was
non-buildable. 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...@
push 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: open
On 15 January 2016 at 10:01, Thierry Carrez 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?
Than
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
owever, I don't feel strongly enough to try and stop
this.
Due to limited time, I'd not like to be a driver... but would like to
be part of the seed group of cores. If this is to happen, it seems
reasonable to map stable-maint-core -> stable-maint project.
We've traditionall
it clone master # == version 1
$ echo foo > stuff.txt
$ git add stuff
$ git commit stuff.txt -m "Daviey's awesome value-add"
# # should still == version 1, but without a centralised reference
marker it will be version 2.
--
Kind Regards,
Dave Walker
___
cycles, but I would suggest that it could be re-added.
[0] https://wiki.openstack.org/wiki/DepFreeze
[1] https://wiki.openstack.org/wiki/FeatureFreeze
--
Kind Regards,
Dave Walker
__
OpenStack Development Ma
unge the tags after the release is no longer supported by upstream.
In my mind, we are then truly treating each commit as a release AND we
benefit from not needing hacky tooling to fake this.
--
Kind Regards,
Dave Walker
> merge, but would still need a plan 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
On 24 July 2015 at 15:26, Boris Bobrov wrote:
> On Friday 24 July 2015 09:29:32 Dave Walker wrote:
>> On 24 July 2015 at 05:00, Julian Edwards wrote:
>> Tl;DR is that the *User* management can come from LDAP via the
>> Identity driver, but the Project/Tenants and Roles on t
e idea for an external AuthN driver
to plug into legacy RBAC systems but this area of Keystone wants to
focus on Federation rather than extending interaction at other levels.
You may fine the thread of interest:
http://lis
ats, i'm
still healthily represented.
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: ope
reference, 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 Mail
On 13 July 2015 at 21:58, Ian Cordasco wrote:
> On 7/13/15, 15:09, "Dave Walker" wrote:
>
>>
>>Therefore, these distro's would need to increment the distro epoch if the
>>upstream version (without the upstream epoch) is lower than the version
>>cur
thout the upstream epoch) is lower than the version
currently in their archives.
I am not sure how rpm based distro's handle '!' in the upstream version.
[0]
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
--
Kind Regards,
Dave Walker
_
On 9 July 2015 at 11:59, Dave Walker wrote:
> On 9 July 2015 at 11:43, Robert Collins wrote:
>> On 9 July 2015 at 21:13, Thierry Carrez wrote:
>
>
> As you said later, if it is green - then the code base has presumably
> proved it can work with that version, so sync
irements, but I suppose they need to learn to trust it.
As you said later, if it is green - then the code base has presumably
proved it can work with that version, so sync' it across.
--
Kind Regards,
Dave Walker
__
re that
their archives fulfil the versions as limited by requirements.txt.
This change actually makes it a better experience for them, as they
have a more deterministic view of what will work.
It doesn't solve the issue of distributions chasing the lowest
version, but I am not sure that is an
On 7 July 2015 at 15:44, Jeremy Stanley wrote:
> On 2015-07-07 13:24:00 +0100 (+0100), Dave Walker wrote:
> [...]
>> I am interested to hear why the convention in documentation for it to
>> be lower case.
> [...]
>
> Seems like this question comes up once for every
ention[0] of using
lower case so I amended it to follow.
I am interested to hear why the convention in documentation for it to
be lower case.
[0]
https://wiki.openstack.org/wiki/Documentation/Conventions#Service_and_project_names
--
Kind Regards,
Dave Walker
_
e 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
on how to solve 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
ntered. We've started to get away from that, and it feels like a
mistake.
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
OH, if Canonical doesn't release a version of 3.4 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
. We need to do this when the Gate is wedged, and
requires two or more concurrent backports to unwedge.
Such as: https://review.openstack.org/#/c/163378/
As Ihar points out, the test coverage mandates that we do this.. which
nicely helps us provide some assurance that the branch is constantly
rele
As you can 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 li
On 10 June 2015 at 15:12, Thomas Goirand 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
branch:master,n,z
I did start working on a jenkins job to check distro's to see what
version of package was already in releases, but it wasn't really
reliable enough, 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
her
get-orig-source (inspecting the generation 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.
--
ocal patches, but
does not support the model of allowing the user to rebase using git.
Perhaps tags ARE superior for this?
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not for usage questions)
Unsubscri
pass, with the usual
case being changing of bound direct or indirect dependencies.
If we grab a recent point release tarball, and put it back through the gate
with the same declared requirement bounding - it will still fail (even
though it passed when the release was cut).
--
Kind
Responses inline.
On 29 May 2015 6:15 pm, "Haïkel" wrote:
>
> 2015-05-29 15:41 GMT+02:00 Thierry Carrez :
> > Hi everyone,
> >
> > TL;DR:
> > - We propose to stop tagging coordinated point releases (like 2015.1.1)
> > - We continue maintaining stable branches as a trusted source of stable
> > upd
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,
Da
considered a mere library,
compared to a project that wouldn't have a release.
I also wondered if it might make sense for us to do a better job of
storing metadata of what the shasums of projects used to pass gate for
a given commit - as this might be both useful as a "known good state&quo
re a core library like
PBR can just support 1.0 and n-1 - so would each release keep support
for pbr's major and minor?
(PS. I really like PBR)
--
Kind Regards,
Dave Walker
__
OpenStack Development Mailing List (not
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
raise SystemExit("Please use pip 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 Tayl
as being logged. Without this mindset, the
channel (and project?) merely becomes a cabal developers area.
[0] http://eavesdrop.openstack.org/irclogs/
[1] http://irclogs.ubuntu.com/2015/01/01/
--
Kind Regards,
Dave Walker
__
OpenStack
+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 wrote:
> Hiya-
>
> Flavio has been actively involved in stable branch maintenance for as long
> as I can remember, but it looks like his +2 abiliti
ew.openstack.org/#/c/706/
I think shortly after this, it was pretty widely agreed that fixing
this in Nova is not the correct layer. Personally, I struggle
thinking qemu or libvirt is right layer either. I can't think that
treating a console as a flat log file is the best
I think:
http://bazaar.launchpad.net/~ubuntu-reports-dev/ubuntu-reports/trunk/view/head:/server/reportgenerator.py
--
Kind Regards,
Dave Walker
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 15 November 2014 21:22, Jeremy Stanley 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 intr
On 15 November 2014 20:23, Robert Collins wrote:
> On 16 November 2014 09:03, Dave Walker wrote:
>> On 15 November 2014 19:51, Robert Collins wrote:
>>> It probably needs to be backed out of stable/icehouse. The issue is
>>> that we were installing unittest2 via dist
ranches, which for stable 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 goe
https://review.openstack.org/#/c/134727/
This should unblock stable/juno, allowing this to progress.
Please be reviewing :)
--
Kind Regards,
Dave Walker
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
g through arbitrary url prefix for
keystone, glance-api and keystone. The services currently have quite
naive support for an arbitrary prefix and expect to own document root.
Whilst your proposal does head into solving this issue, I'd like to
stress that it shou
not really 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
e can do without 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
thanks.
--
Kind Regards,
Dave Walker
On 16 October 2014 19:58, David Chadwick 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
On 16 October 2014 20:07, David Stanek wrote:
> 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 not
provided to keyston
eration protocol. So I'd
> rather explore adding more support for additional federation
> protocols/standards, rather than making our own third backend.
>
> Steve
>
> Dave Walker wrote on 10/16/2014 02:15:07 PM:
>
>> From: Dave Walker
>> To: OpenStack Develo
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 K
ted?
Are we tracking open-bugs on Master well enough as also affecting stable
releases?
I do not think we are struggling primarily with technical issues, but
procedural issues.
I hope we are all agreed we /need/ something. Let's talk about 'what' and
'how', rather than
ng the fix down 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-d
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
89 matches
Mail list logo
