available in a given OS version! :)
I hope this helps,
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
htt
anyone from the Barbican thought about this,
and/or is there any workaround this? Going to production without any
possibility to test with fake certs is a little bit annoying... :P
Cheers,
Thomas Goirand (zigo)
__
OpenSt
>> On Oct 31, 2018, at 2:29 PM, Thomas Goirand wrote:
>>
>> Hi,
>>
>> It took me a long long time to figure out that my SSL setup was wrong
>> when trying to connect Heat to rabbitmq over SSL. Unfortunately, Oslo
>> (or heat itself) never warn me that somet
t a wishlist... :)
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/m
k-cluster-installer
To get in touch, contribute, or ask for support, please join the team's
IRC channel #debian-openstack on the OFTC network.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usag
On 10/26/18 7:11 PM, Zane Bitter wrote:
> On 26/10/18 5:09 AM, Thomas Goirand wrote:
>> On 10/22/18 9:12 PM, Zane Bitter wrote:
>>> On 22/10/18 10:33 AM, Thomas Goirand wrote:
>>>> This can only happen if we have supporting distribution packages for
>>>&
On 10/22/18 9:12 PM, Zane Bitter wrote:
> On 22/10/18 10:33 AM, Thomas Goirand wrote:
>> This can only happen if we have supporting distribution packages for it.
>> IMO, this is a call for using Debian Testing or even Sid in the gate.
>
> It depends on which versions we choo
,
Thomas Goirand (zigo)
__
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
gt;> maintaining it, and where those contributors prefer to do the work.
>
> Thus far I'm not hearing any volunteers. If that continues to be the
> case, I'll just keep it on bitbucket as that's the minimal change.
Could you please move it to Github, so that at least, it's
ctual distros we have identified as popular.[2] It's also
> important that every project be testing on the same distro at the end of
> a release, so we can be sure they all work together for users.
I find very disturbing to see the project only leaning toward these only
2 distributions. Wh
type of networks.
Cheers,
Thomas Goirand (zigo)
__
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
ebian is full Python 3 now...). In this
example, we're just over the wire, and it was supposed to be the same.
Yet, only an integration test could have detect it (and I discovered it
running puppet-openstack on Debian).
Cheers,
Thomas Goirand (zigo)
___
g like
>>> os_placement instead?
>
> Either one works for me. Though I'm pretty sure that it isn't necessary.
> The reason it isn't necessary is because the stuff in the top-level
> placement package isn't meant to be imported by any
Just like we have:
nova: OpenStack compute
No? Is it too late?
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject
On 08/30/2018 11:33 PM, Jeremy Stanley wrote:
> On 2018-08-30 22:49:26 +0200 (+0200), Thomas Goirand wrote:
> [...]
>> I really don't want this. I'm happy with things being sorted in
>> multiple lists, even though I'm subscribed to multiples.
>
> I understa
On 08/30/2018 08:57 PM, Chris Friesen wrote:
> On 08/30/2018 11:03 AM, Jeremy Stanley wrote:
>
>> The proposal is simple: create a new openstack-discuss mailing list
>> to cover all the above sorts of discussion and stop using the other
>> four.
>
> Do we want to merge usage and development onto
On 08/08/2018 04:38 PM, Chris Dent wrote:
> On Wed, 8 Aug 2018, Thomas Goirand wrote:
>
>> I'd be more than happy to have a better logging without the need of
>> paste/pastescript, but so far, that's the only way I found that worked
>> with uwsgi. Do you know an
On 08/08/2018 10:43 AM, Chris Dent wrote:
> On Wed, 8 Aug 2018, Thomas Goirand wrote:
>
>> If you don't configure uwsgi to do any special logging, then then only
>> thing you'll see in the log file is client requests, without any kind of
>> logging from th
oing to be released with Py3.7? In Debconf18 in Taiwan, Doko
didn't seem completely sure about it.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubsc
gi application. To have proper logging, one needs to
add, in the uwsgi config file:
paste-logger = true
If you do that, then you need the python3-pastescript installed, which
itself depends on the python3-paste package.
Really, I don't see how an
.2 # MIT |
> | upstream-institute-virtual-environment |
> elements/upstream-training/static/tmp/requirements.txt | 147 | Paste==2.0.3
> |
> +++--+--------
on i think thie need to be a comuntiy wide discussion and
> goal that is informed by what distros are doing but
> not mandated by what any one distro is doing.
> regards
> sean.
Postponing any attempt to support anything current is always a bad idea.
I don't see why there's eve
we are ready to do yet), these kinds of patches will be on a best effort
> basis.
This is exactly what I'm complaining about. OpenStack upstream has very
wrong priorities. If we really are to switch to Python 3, then we got to
make sure we're current, because that'
yet:
https://review.openstack.org/#/c/586050/
https://review.openstack.org/#/c/586716/
That'd be ok if at least there was some reviews. It looks like nobody
cares but Debian & Ubuntu people... :(
Cheers,
Thomas Goirand (zigo)
___
On 07/12/2018 10:38 PM, Thomas Goirand wrote:
> Hi everyone!
>
> [...]
Here's more examples that shows why we should be gating earlier with
newer Python versions:
Nova:
https://review.openstack.org/#/c/584365/
Glance:
https://review.openstack.org/#/c/586716/
Murano:
https://b
that's what I would like to be fixed.
Using either Fedora or SuSE is fine to me, as long as it gets latest
Python language fast enough (does it go as fast as Debian testing?). If
it's for doing unit testing only (ie: no functional tests using Qemu,
libvirt and other compon
ie. When
this happens, moving faster with Python 3 versions will be mandatory for
everyone, not only for fools like me who made the switch early.
:)
Cheers,
Thomas Goirand (zigo)
P.S: A big thanks to everyone who where helpfu
including
#openstack-neutron and #openstack-fwaas), and I'll reply if it's office
hours in Geneva/France, or late in my evening.
I hope the above helps,
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mai
On 06/20/2018 04:23 PM, Thomas Goirand wrote:
> or using the Debian backports repository at:
>
> http://stretch-queens.infomaniak.ch/debian
I really meant:
deb http://stretch-queens.debian.net/debian \
strech-queens-backports main
deb http://stretch-queens.debian.n
have to use
upstream Debian repository for Stretch), as it lacks a proper Python 3
support, and still no Luminous release uploaded to Sid. I intend to
attempt to fix this, to get a chance to get this in time for Buster.
Cheers,
n of
libvirt higher than it claims at the moment. I'm stating that,
especially because we had this topic a few weeks ago.
Thoughts anyone?
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage que
On 06/14/2018 01:10 PM, Erlon Cruz wrote:
> Hi Thomas,
>
> The reserved_percentage *is* taken in account for non thin provisoning
> backends. So you can use it to spare the space you need for backups. It
> is a per backend configuration.
Oh. Reading the doc, I thought it was only for thin provisi
e for thin provisioning only. If
this doesn't exist, would such new option be accepted by the Cinder
community, as a per volume node option? Or should we do it as a global
setting?
Cheers,
Thomas Goirand (zigo)
__
OpenSt
e maintainer, and users
who have to download the new version, etc. We're not really concerned by
branches, all we care is if there's a new tag to be packaged.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailin
e considered the past release to maintain, rather than
the one to focus on. If we can't get Sid, then at least should we
consider the non-LTS (always latest) Ubuntu releases?
Cheers,
Thomas Goirand (zigo)
__
OpenStack
ming anyone on
purpose...).
If you're not happy about the way Doug is doing, just make it happen the
way you prefer. As long as it's done soon, everyone will be happy.
Cheers,
Thomas Goirand (zigo)
__
for the activated plugin), and
that http-socket / https-socket is also dynamic, ie: --https-socket is
used on the command line if a pair of certificate + private key is found
on the hard disk under /etc/neutron/ssl. See
https://salsa.debian.org/openstack-team/service
t possible to have Horizon work with both v4 and v5, which
would be even better (of course, package maintainers would have to set
correct links to the right font file, but that's a packaging detail).
Cheers,
Thomas Goirand (zigo)
nt in fa-solid-900
so we could simply replace the old v4 font by fa-solid-900 only.
Your thoughts?
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-
ew fa-solid-900 files.
Second, it'd be nice if Horizon could adapt and use the new v5
font-awesome, so that the problem is completely solved.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (n
t I should know?
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailma
On 05/20/2018 06:24 PM, Matthew Treinish wrote:
> On Sun, May 20, 2018 at 03:05:34PM +0200, Thomas Goirand wrote:
>> Thanks for these details. What exactly is the trouble with the Swift
>> backend? Do you know? Is anyone working on fixing it? At my company,
>> we'd be ha
inder, today Glance (thanks to Matt)
and Nova, and it's looking like I got one remaining issue with Neutron
that I didn't have time to investigate fully yet (got to dig in the
logs). But it's looking good. Hopefully, next week I'll be
erything else? If
I'm not mistaking, the API is described at:
https://www.python.org/dev/peps/pep-0554/ (ie: PEP554), and that, if I
understand correctly, works around the global interpreter lock issue. As
much as I could see, uws
/glance/common/wsgi.py
I can confirm this through my last week (bad) experience with Eventlet
over SSL.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubs
king on it?
Also, what's the status of NoVNC with Python 3? I saw lots of print
statements which are easy to fix, though I even wonder if the code in
the python-novnc package is useful. Who's using it? Nova-novncproxy?
That's unlikely, since I didn't package a Python 3 version fo
On 05/19/2018 07:54 PM, Matthew Treinish wrote:
> On Sat, May 19, 2018 at 07:04:53PM +0200, Thomas Goirand wrote:
>> using:
>> - RBD backend
>> - swift backend
>> - swift+rgw
>
> As for the backend store choice I don't have any personal experience using
, there's no need to manually do the symlink, you can use instead:
a2ensite uwsgi-glance-api.conf
Cheers,
Thomas Goirand (zigo)
[uwsgi]
### Generic UWSGI config ###
# Override the default size for headers from the 4k default.
buffer-size =
asks api and
> image import stuff) This shouldn't be hard to fix, and I've had
> patches up to address these for months:
>
> https://review.openstack.org/#/c/531498/
> https://review.openstack.org/#/c/549743/
Do I need to backport these patches to Queens to run Glance the
Glance so that it can work with uwsgi and
Apache mod_wsgi.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubs
ks are:
- eventlet with or without SSL, using Python 2
- eventlet without SSL with Python 3
- apache with or without SSL without swift backend
As much as I understand, we're only testing with eventlet with Python 2
and 3 without SSL and file backend. That's 2 setups out of 24... C
None,
u'name': u'tempest-setUp-2113966350-subnet'}, router: {u'status':
u'ACTIVE', u'external_gateway_info': {u'network_id':
u'c6cf6d80-fcbb-46e6-aefd-17f41b5c57b1', u'enable_snat': True,
u'external_fi
wsgi-py3) and as a quick look the only difference is
> a module
> specified in LoadModule apache directive.
> I haven't tested it yet, but it seems worth explored.
>
> Akihiro
libapache2-mod-wsgi-py3 is what's in use in all Debian packages for
OpenStack, and it works we
e wrong
place? If so, how could this be fixed?
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lis
So what I need, as far
as Debian is concerned is:
- Python 3.6 & Django 1.11 for Rocky (that's for Debian Buster).
- Python 3.6, probably even 3.7 and Django 2.0 for Stein (that's for
after Buster is released).
Cheers,
Thomas Goirand (zigo)
__
Hi,
It has been decided that, in Debian, we'll switch to Django 2.0 after
Buster will be released. Buster is to be frozen next February. This
means that we have roughly one more year before Django 1.x goes away.
Hopefully, Horizon will be ready for it, right?
Hoping this helps,
Cheers,
T
On 05/02/2018 10:25 AM, Chris Dent wrote:
> On Wed, 2 May 2018, Thomas Goirand wrote:
>
>> What was disturbing was that, doing the same request with curl worked
>> perfectly. Even more disturbing, it looked like I was having the issue
>> nearly always in virtualbox
Thoughts anyone?
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-b
istros and
everywhere.
I can review patches in sqla-migrate, as I'm still core-reviewer there,
though I'm not sure I know enough to do it myself.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not
m Python
> 2.7 to 3.6 as the job default? I can see some value in each option.
I'd love to see gating on both Python 3.5 and 3.6 if possible.
Also, can we restart the attempts (non-voting) gating jobs with Debian
Sid? That's always were
On 04/13/2018 02:48 PM, Thomas Goirand wrote:
> On 03/17/2018 09:34 AM, Emilien Macchi wrote:
>> ## Challenges
>>
>> - Some services aren't fully Python 3
>
> To my experience switching everything to Py3 in Debian, the only issues
> were:
>
> - manila-
y don't care about),
you could just add these patches at the packaging level.
I hope this helps,
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-de
ase let me know,
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/m
https://www.redhat.com/archives/libvir-list/2017-February/msg01295.html
So, because of these bugs, would you already advise Nova users to use
libvirt 3.2.0 for Queens?
Cheers,
Thomas Goirand (zigo)
__
OpenStack Developme
.debian.org/DebianReleases#Release_statistics
With this logic and considering Stretch was released last year in June,
after Stein is released, Buster will probably start its freeze. If the
Debian freeze happens later, good for me, I'll have more time to make
Stein better. But then Debian
On 03/27/2018 04:39 PM, Tom Barron wrote:
> On 27/03/18 15:53 +0200, Thomas Goirand wrote:
>> Building the packages worked surprisingly well. I was secretly expecting
>> more failures. The only real collateral damage is:
>>
>> - manila-ui (no Py3 support upstream)
>
On 03/27/2018 04:20 PM, Jeremy Stanley wrote:
> On 2018-03-27 15:53:34 +0200 (+0200), Thomas Goirand wrote:
> [...]
>> I'd really love to have Sid as a possible image in the infra
> [...]
>
> This has unfortunately been rotting too far down my to do list for
> me t
Worse, some of them
cannot even be identified (I couldn't find out what version from
upstream it was). So even if this package is ready, I can't upload it to
Debian in such state.
Cheers,
Thomas Goirand (zigo)
__
ch/debian \
stretch-queens-backports-nochange main
(sorry for the email client that is wrapping this...)
this repository contains a full Queens backport for Stretch btw, and
also holds a version of keystone (with Apache), so make sure you're
using the correct uwsgi v
oc,
and then that file isn't built reproducibly. That's harder to detect,
and easier fixed upstream.
Cheers,
Thomas Goirand (zigo)
[1] https://reproducible-builds.org/
__
OpenStack Development Mailing List (not
tch? It's
rather easy to do, as the revert to Apache is just a single git commit.
> Do you happen to have any more logging information?
That's what was really frustrating: no log at all on the server side,
just the client...
Cheers,
Thomas Goirand (zigo)
__
lazy-apps = true
paste-logger = true
logto = /var/log/keystone/keystone-admin.log
name = keystone-admin
uid = keystone
gid = keystone
chdir = /var/lib/keystone
die-on-term = true
Has this happened to anyone else? Is there one option above which is
wrong? Why is this happening?
happen as early as possible in the cycle.
Also, you don't *HAVE* to upgrade them *ALL* in a single cycle and give
downstream package maintainers so much work! :)
Cheers,
Thomas Goirand (zigo)
__
OpenStack Develop
ady an
XStatic package for the font-awesome which can be used. I do believe it
would be very much OK to add such a requirement to heat-dashboard, since
it is already one of the requirements for Horizon.
Altogether, thanks a lot for your care, as always, the OpenStack
community turns out to be comp
rce package now
carries a python-pyldap transition package, which installs python-ldap.
What's the procedure? Should I first send a patch to the global-reqs
repo first?
Cheers,
Thomas Goirand (zigo)
__
OpenStack Developm
cause.
>
> Sorry to bring troubles to you. We will be grateful if you could wait
> for a little longer.
>
> Best Regards,
>
> Xinni
Hi,
Thanks for this message. This lowers the frustration! :)
Let me know if there's any patch
hat at least the code builds/installs in
downstream distributions
2/ Remove the code completely from os-xenapi
I'd prefer the later, but I don't mind much. Your thoughts?
Cheers,
Thomas Goirand (zigo)
__
OpenStack
ase-cycles-ptg-rocky
>
> Please add the topics you'd like to cover.
I really wish I could be there. Is there any ways I could attend
remotely? Like someone with Skype or something...
Cheers,
Thomas Goirand (zigo)
__
Ope
uess I'll simply skip manila-ui for this release (since all of
Horizon is already switched to Python 3 on my side). I'm expecting to
see more of these Horizon plugins to not be ready (I haven't completely
finished that part...).
I hope this helps,
Cheers,
Thomas Goirand (zigo)
___
On 02/21/2018 05:54 PM, Corey Bryant wrote:
>
>
> On Wed, Feb 21, 2018 at 9:35 AM, Thomas Goirand <mailto:z...@debian.org>> wrote:
>
> Hi there!
>
> I'm having big trouble package heat-dashboard for Debian. I hope I can
> get he
rrectly installed, and writing its secret key material as it should,
in /var/lib/openstack-dashboard? It's probably due to me, but here, how
can I make heat-dashboard unit test behave during package build? What's
this "No local_s
On 02/16/2018 03:42 PM, Petr Kovar wrote:
> On Thu, 15 Feb 2018 09:31:19 +0100
> Thomas Goirand wrote:
>
>> Hi,
>>
>> Since I'm getting some pressure from other DDs to actively remove Py2
>> support from my packages, I'm very much considering switching
nstack.org/544809
Cheers,
Thomas Goirand (zigo)
__
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
meaningful
documentation, almost no project description isn't going to make it very
attractive for new contributors.
Could we get this improved?
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List
://github.com/hgrecco/pint/issues/577
None of these bug entries received patches. I attempted to understand
myself, though it is above my skills.
Could anyone help and provide a patch?
Cheers,
Thomas Goirand (zigo)
__
OpenStack
On 12/15/2017 05:52 PM, Matt Riedemann wrote:
> On 12/15/2017 9:15 AM, Thomas Goirand wrote:
>> Not only that. Everyone is lagging a few release behind, and currently,
>> upstream OpenStack don't care backporting to older releases.
>
> Can you clarify this please? T
ed in stable too, otherwise you face new issues trying to get a
bugfix. And that's why we have stable.
> I understand the belief that nobody will run the intermediaries.
Not only that. Everyone is lagging a few release behind, and currently,
upstream OpenStack don't care backporting
On 12/14/2017 03:16 PM, Ed Leafe wrote:
> On Dec 14, 2017, at 3:01 AM, Thomas Goirand wrote:
>>
>> As a package maintainer who no longer can follow the high pace, I very
>> much support this change.
>
> So you’re saying that you would be ignoring any intermediate re
On 12/13/2017 05:17 PM, Thierry Carrez wrote:
> So... What do you think ?
As a package maintainer who no longer can follow the high pace, I very
much support this change.
Cheers,
Thomas Goirand (zigo)
__
OpenSt
the pilot can be shown working the conversation with
> the community becomes a little easier.
Doing this kind of a patch at first on a few project's tox.ini,
absolutely! I might even start with Horizon and PBR (yes, there's a
problem there as well... which I haven't reported yet). Th
e variables set.
Your thoughts?
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/
ntinue to do so if nothing is done.
Instead of thinking "this will be more work", why don't you think of the
LTS as an opportunity to only release OpenStack Chef for the LTS? That'd
be a lot less work indeed, and IMO that's a very good opportunity for
you to scale do
ded to do Newton on my free time. I probably wont be able to
do that again for Queens, if I'm not paid for it: it's clearly not a
sustainable situation.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Develo
f you were shipping a nova.conf in the
correct location, the Debian package would have to fix these directives.
I've seen that Ubuntu does something similar also.
I still didn't have any reply on my PBR change proposal. Your thoughts?
Cheers,
Thomas Goirand (zigo)
___
Hi,
Could someone write something relevant, instead of the current
placeholder? See here:
https://pypi.python.org/pypi/python-zunclient
and see that "this is a hard requirement".
Cheers,
Thomas Goi
eselected destination.
Does this seem a good plan? Please comment on the above.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.
On 10/09/2017 12:36 PM, Jesse Pretorius wrote:
> There has been an objection from the OpenStack package maintainer for
> Debian, but that objection has been to the use of the relative path of
> /etc. Thomas Goirand, could you please indicate whether you support the
> use of the rela
7;s data_files is designed for handling
config files at all. Which is the very reason why I think it's broken to
use it the proposed way.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for us
On 10/09/2017 11:20 AM, Luigi Toscano wrote:
> On Saturday, 7 October 2017 12:30:54 CEST Thomas Goirand wrote:
>> Though people doing the packaging will suffer. Please don't throw the
>> baby over the wall, and let's fix the issue.
>
> This is an overstatement.
Par
the situation! Starting this thread was
definitively a very good idea, especially considering different people
have different opinions.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for us
1 - 100 of 696 matches
Mail list logo
