nvironment variable. Something like:
export OSLO_CONFIG_FILE_DEST=/usr/share/nova-common
This way, I wouldn't have to manually move/copy/delete/regenerate config
files by hand in debian/rules.
I hope this helps,
Cheers,
Thomas Goirand (zigo)
__
case. That's not what OpenStack
used to do, and that's not fair. Let's fix things properly *first*
please, maybe by discussing the PBR fix I linked to. Can we agree that
this is the pragmatic easy (but maybe temporarily) way to fix the issue,
even if it's no
uch prefer if I could avoid it. This would bring
inconsistency which is always better to avoid.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ
obert Collins wrote it had to be fixed in
setuptools. Which is why all patches have been reverted so far.
While I may agree with Robert, I think we had to choose for a pragmatic
(even temporary) solution, and I don't understand why it's been years
that this stays unfixed, especially when
ck infra is to me a step in the
wrong direction. We should aim at full integration with the rest of
OpenStack, not getting out.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for
there's not much added work to be done to get all the
services uploaded, especially if the package only needs update.
Typically, I was needing 2 to 3 weeks (on each beta or RC) to get all
dependency into shape, and a few days for the services on top.
Cheers,
dore is a very good example. It build-depends on oslotest (to run
unit tests), which itself needs os-client-config, oslo.config, which
itself ... no need to continue, once you need oslo.config, you need
everything else. So to continue to package something like Stevedore, we
need nearly the full
On 02/19/2017 06:44 AM, gustavo panizzo wrote:
> On Sun, Feb 19, 2017 at 01:10:21AM +0100, Thomas Goirand wrote:
>> On 02/18/2017 05:14 PM, Andrew Bogott wrote:
>>> Does this
>>> announcement mean that the Mirantis apt servers (e.g.
>>> mitaka-jessie.pkgs.mir
someone external from the company to
express discontent to the Mirantis marketing team about discontinuation
of this service. So be my guest...
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing
u new maintainers.
Even within the team, there's unfortunately *a lot* of strong package
ownership.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscri
27;t have such an
infrastructure anymore at my disposal, Mirantis even is destroying the
server I used to work on (at this point in time, the FTP data may even
already be lost for the older releases...).
Cheers,
Thomas Goirand (zigo)
_
On 02/16/2017 12:20 PM, Ondrej Novy wrote:
> Hi,
>
> 2017-02-16 0:45 GMT+01:00 Thomas Goirand <mailto:z...@debian.org>>:
>
> Yes, you've done some work, and many thanks for it, it has been very
> useful. However the reality is: since I stopped after the
On 02/15/2017 07:11 PM, Ondrej Novy wrote:
> Hi,
>
> 2017-02-15 13:42 GMT+01:00 Thomas Goirand <mailto:tho...@goirand.fr>>:
>
> Over the last few months, I hoped for having enough strengths to
> continue my packaging work anyway, and get Ocata packages done
watcher
- zaqar
Hopefully, Canonical will continue to maintain the other 15 (more
core...) projects in UCA.
Thanks for the fish,
Thomas Goirand (zigo)
P,S: To the infra folks: please keep the packaging CI as it is, as it
will be useful for the lifetime of Stretch.
_
watcher
- zaqar
Hopefully, Canonical will continue to maintain the other 15 (more
core...) projects in UCA.
Thanks for the fish,
Thomas Goirand (zigo)
P,S: To the infra folks: please keep the packaging CI as it is, as it
will be useful for the lifetime of Stretch.
_
also get
rid of the admin and internal endpoint in the service catalog.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?
On 01/24/2017 04:15 PM, Julien Danjou wrote:
> On Tue, Jan 24 2017, Thomas Goirand wrote:
>
>> FYI, this was a very unfortunate upload of the latest webob version in
>> Sid, which was reverted. IMO though, OpenStack should prepare itself to
>> support the latest version t
- gnocchi
- keystone
- nova
- keystonemiddleware
- oslo.middleware
There's probably more, but that's what was detected rebuilding all of
the Debian archive after webob 1.7.x was uploade in Sid.
Cheers,
Thomas Goirand (zigo)
_
se changes have nothing to do there, they are to be done on
upstream code.
2/ Never one should touch the master branch of these repositories (only
debian/* are to be edited).
Please abandon all of your changes for the deb-* Gerrit repos.
Thanks for that work anyway,
Cheers,
Thomas G
On 10/18/2016 08:25 PM, Monty Taylor wrote:
> On 10/18/2016 12:05 PM, Adam Harwell wrote:
>> Inline comments.
>>
>> On Wed, Oct 19, 2016 at 1:38 AM Thomas Goirand > <mailto:z...@debian.org>> wrote:
>>
>> On 10/18/2016 02:37 AM, Ian Cordasco wro
even have
> a package manager AFAIK.
YOUR preference may not be the same as the ones deploying. For example,
if I was to deploy, I'd prefer if all components where from a single
distribution vendor, even if the image gets bigger at the end. It is
easier to address security vulnerabilities
#x27;s an implementation
detail that could even be left to package maintainers (I don't know the
exact details of Octavia here though...).
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (n
On 10/18/2016 02:37 AM, Ian Cordasco wrote:
> On Oct 17, 2016 7:27 PM, "Thomas Goirand" <mailto:z...@debian.org>> wrote:
>>
>> On 10/17/2016 08:43 PM, Adam Harwell wrote:
>> > Jim, that is exactly my thought -- the main focus of g-r as far as I was
> others thought it would be prudent to go the g-r route anyway.
It is, and IMO you should go this route.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscr
e to deal with it with the package
maintainer (probably best through the Debian BTS).
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-r
eam members using stackalytics to judge activity?
Sorry to say it strait this way, but that's really none of your
business. Please avoid this type of remarks in the future.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Devel
ics has it wrong, when the electorate
script for the PTL election is correct. Here's the script for getting
commits:
https://github.com/openstack-infra/system-config/blob/master/tools/owners.py
What part of Stackalytics is gathering the commits?
Waiting for a full month to solve this issue
hink we need to strongly consider blocking it and revisiting these
> issues post newton.
>
> -Sean
Blocking a version of oslo.db just because of your 6th sense tells you
it may have introduce some issues isn't the best way to decide. We need
a better investigation than just this, an
ll do my best to continue to drive the project, and hope to gather
more contribution every day. Every contributor counts.
Cheers,
Thomas Goirand (zigo)
P.S: It maybe will be a bit hard to find out who can vote, because only
the debian/newton branch should count, and currently Stackalytics is
cou
k infra).
Feel free to join and/or add stuff to the agenda.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subj
example,
Django, SQLAlchemy, etc.). For these, from a distro perspective, the
wider range of version the better.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
t currently does). But I
don't agree that every project needs to be dumb and increase lower
bounds when they in fact don't need to do so. IMO they should follow
what Swift does: test lower bounds. Currently John does this manually.
In an ideal world, every project would be individually
lower requirements than
other projects in OpenStack. Yet, Swift is fully co-installable with all
other OpenStack projects. They just support lower versions than others.
> If OpenStack drops the illusion of coinstallabili
On 08/09/2016 08:25 PM, Julien Danjou wrote:
> On Tue, Aug 09 2016, John Dickinson wrote:
>
>> I'd like to advocate for *not* raising minimum versions very often. Every
>> time
>> some OpenStack project raises minimum versions, this change is propagated to
>> all projects, and that puts extra bur
icked out, as it becomes not maintainable (it
downstream distros or otherwise).
On 08/01/2016 04:23 PM, Jay Pipes wrote:
> or a particular greenlet library du jour
That's another story which can be debated, IMO.
Cheer
49070 add ocata goal "switch to oslo
> libraries"
Thanks a lot for working on this. Everything is well thought. Just one
thing, probably, "release goal" would be a better fit for naming this,
so that it puts the emphasis on deliverables.
Cheers,
Thomas Goirand
;s
contribution ratio dropped. Does that makes project Bob healthier just
because she left? I don't think it does. And that's not what our ruleset
should enforce. Our rules should push for more contributions, not less. [1]
If we want to make collaboration going better, it's going
t; it with internal tools and meetings ? why accept the oversight of the
> Technical Committee ?).
A project can still be useful for everyone with a single vendor
contributing to it, even after a long period of existence. IMO that's
not the issue w
;
> Thoughts?
>
> Rob
Please go ahead. Debian Sid has 1.5.5, so even if we don't want to,
Debian will be using that version. It's better to be in sync.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Develop
downstream distros?
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
y default (python3-debian is a good example).
On 06/24/2016 10:25 AM, Daniel P. Berrange wrote:
> Please lets not derail discussions about completing Py3 support by
> opening up the can of worms wrt dropping Py2.
The point I was trying to make is that the foreseeable drop of Py2
should be a
t; to reach, but it's not really a
big deal if we don't reach it?
Cheers,
Thomas Goirand (zigo)
P.S: Again, thanks Victor for your awesome work.
__
OpenStack Development Mailing List (not for usage questions)
Unsub
On 06/22/2016 06:36 PM, Nate Johnston wrote:
> On Wed, Jun 22, 2016 at 05:55:48PM +0200, Thomas Goirand wrote:
>
>> Does neutron-fwaas also use "neutron" as launchpad package for bug report?
>
> Yes we do, just add the 'fwaas' tag to the bug. Thanks!
&
n just filing a bug.
And BTW, here's the bug for networking-sfc:
https://bugs.launchpad.net/networking-sfc/+bug/1595211
Does neutron-fwaas also use "neutron" as launchpad package for bug report?
Cheers,
Thomas Goirand (zigo)
On 06/22/2016 02:54 PM, Jeremy Stanley wrote:
> It looks like "openstackgerrit" (gerrit change reports) is already
> there, but "openstack" (channel logging) and "openstackstatus"
> (infra status notifications, success submissions) are not yet
> because the channel is not in the "meetbot_channels"
On 06/12/2016 10:45 PM, Monty Taylor wrote:
> On 06/11/2016 10:13 PM, Robert Collins wrote:
>> On 12 June 2016 at 11:31, Thomas Goirand wrote:
>>> On 06/11/2016 05:02 AM, Robert Collins wrote:
>> ...
>>> Then keystone.conf ends up installed in /usr/etc/keystone
using this architecture: I only checked that
all packages were available.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstac
ad in Debian
is that this package will also reach Ubuntu (through automated sync from
Debian).
> (Currently I've rolled my own processes for
> generating Debian packages for Ubuntu Trusty and Xenial.)
Please join IRC, and send
utron.
While all of the above can be implemented at a distribution level, I am
convince that it'd be nicer if it was also considered upstream.
Note that I am hereby talking for Debian & Ubuntu. I don't know the
situation in the RPM world, but I suspect they will have the same ki
ty and QA that we currently have (ie: build on
each git push, full packaged based Tempest CI, etc.).
I hope the above is what everyone expected me to write, and that there's
enough details. I'd happily give more details if one asks. Monty, please
feel free to reply and
ct, 3 remaining projects on 83 is only 4%,
> we are so close! ;-)
>
> The next steps are to port the 3 remaining projects and work on
> functional and integration tests on Python 3.
>
> Victor
Hi Victor,
Thanks a lot for your efforts on Py3.
Do you think it looks like possible to h
http://docs.openstack.org/infra/jenkins-job-builder/
> [2] http://docs.openstack.org/infra/zuul/
> [3] https://www.ansible.com/
What will be the faith of jenkins job builder then? It is already used
by lots of people, including some Debian folks. Will it be maintained?
Cheers,
Thomas Goirand (
ou, Robert, will veto it, and that my patch
wont ever be merged. I'm busy with 380+ packages for OpenStack, and
don't want to waste too much time, so your view here would be useful
before I invest some time on this patch.
Thoughts anyone?
Cheers,
Thomas Goirand (zigo)
___
e list to make sure that it is seen.
FYI, in Debian, there's no direct dependency on dogpile.core. So this
will be a graceful change, I'll just upload the new dogpile.cache and
ask for the removal of dogpile.core.
Will it "just work" for all of OpenStack, thr
Hi,
A number of Fuel components were previously tagged as "9.0". This isn't
compatible with the semver scheme. Could we agree to switch to x.y.z
going forward?
Cheers,
Thomas Goirand (zigo)
__
OpenStack Deve
le who like it are developers, because they just don't
need to care about shared library API/ABI incompatibilities and
regressions anymore.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage
ve just started the
> 'js-generator-openstack' project, which will evolve to handle dependency
> version maintenance, tooling updates, and new project bootstrapping. I
> expect that most of the discussions about "What tools do we use" will
> happen there.
I
iple times. Has
this discussion already happened?
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http
end up with
> lots of processes; for example, a 48-disk node with 2 object servers per
> disk will end up with about 96 object-server processes running. While
> these processes aren't particularly RAM-heavy, that's still a decent
&
ading comes from trusted sources only: it's just too difficult for
no rewards.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.ope
talling from $language manager instead of distro packages, be it in
containers or not, will almost always make you download random blobs
from the Internet, which are of course changing over time without any
notice, loosing the above 3 important features.
Cheers,
Thomas Goirand (zigo)
__
?) to get it right.
Plus all what Matthias wrote...
Cheers,
Thomas Goirand (zigo)
P.S: Again, I'm all but a Go specialist, so I hope I'm not writing too
many wrong things here... Feel free to correct me if I'm wrong.
Go packaging
team will accept contributions (which may later be backported wherever
Canonical people want to store it, if you are a Ubuntu user).
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not f
On 05/09/2016 09:51 PM, Clint Byrum wrote:
> There are all kinds of reasons to pick languages, but I think it would
> be foolish of OpenStack to ignore the phenomenon of actual deployers
> choosing Go to address OpenStack's shortcomings. Whether they're right,
> I'm not sure, but I do know that the
On 05/09/2016 01:33 PM, Hayes, Graham wrote:
> On 08/05/2016 10:21, Thomas Goirand wrote:
>> On 05/04/2016 01:29 AM, Hayes, Graham wrote:
>>> On 03/05/2016 17:03, John Dickinson wrote:
>>>> TC,
>>>>
>>>> In reference to
>>>> http:
runtimes that come with
>> the Linux they're running.
>>
>
> Perhaps for mature languages. But go is still finding its way, and that
> usually involves rapid changes that are needed faster than the multi-year
> cycle Linux distributions offer.
If that's the cas
On 05/08/2016 03:37 PM, Rayson Ho wrote:
> On Sun, May 8, 2016 at 5:16 AM, Thomas Goirand <mailto:z...@debian.org>> wrote:
>> I've heard that upstream for
>> Golang was working on implementing shared libs, but I have no idea what
>> the status is. Does
rigger rebuilds for each and every
reverse dependencies. As the number of Go stuff increases over time, it
becomes less and less manageable this way (and it may potentially be a
security patching disaster in Stable). I've heard that upstream for
Go
igressing! :)
The point that I was making is that I know that there's not more
staffing in Ubuntu either (since we package together everything which is
not server packages), and we're probably at approximately the same
number of people
ing too much of my time to review them. So I just
>> pick it up before packaging a (beta-)version of OpenStack.
>
> I think you've made my point here. Reviewing these changes *is*
> time consuming.
I'm kind of reviewing it: I'm subscribed to the requirements reposito
at.
> All the rest of the discussion is coming
... as ways to avoid issues due to bad code. Let's fix the code, or
avoid the bad one.
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing L
uch work? Maybe we
could give this new workflow a try for a cycle, and see how it works
out? Please, voice your concerns, share your view, etc.
Hoping the above is constructive enough,
Cheers,
Thomas Goirand (zigo)
__
Ope
queue, in time for the final
release. I guess RDO and SuSE people would have the same concern. I'm
not sure how to implement this in such a way that the procedure is
enforced. Ideas welcome.
> If we want there to be a big-tent (a debate worth having) then we're
> going to have loads o
nd this issue by deleting the package from the
repository first.
Which direction does the infra team believe I should take?
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubs
gt; the effort among them would make it easier than each of them doing
> all of the work individually. Sort of like an open source project.
There's 2 options I see to solve the "people reviewing the
global-requirements.txt c
tthew's name, and give-up my contributions, just so that I can
stay polite and pretend everyone is nice? Or let this pattern repeat
itself during another 2 years?
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mai
t summit in Austin at a bunch of the cross project stuff
> along with openstack-ansible stuff though.
Let's meet there at the cross-project sessions then!
Thomas Goirand (zigo)
__
OpenStack Development Mailin
he agenda at the design summit, and I look forward to being able to
> hash this out in more detail then.
On every design summit, I'd like to get this discussion happen with the
doc people, though never, it was
On 04/08/2016 07:47 PM, Matthew Thode wrote:
> On 04/08/2016 11:47 AM, Thomas Goirand wrote:
>> Another thing is that the Debian packages are the only ones available
>> for many services, as Canonical doesn't work on them (these packages are
>> just sync from De
involved in the spec which were drafted to remove Debian (I'm
discovering it today).
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...
This is disgusting, and with no valid reason. The same
way every project should be welcome in the install-guide, contributors
should be welcome, and for all operating systems.
Cheers,
Thomas Goirand (zigo)
__
OpenSta
and
understand the requirements of downstream distributions. Guys, you're
awesome, I love my work, and I love working with you all!
Cheers,
Thomas Goirand (zigo)
signature.asc
Description: OpenPGP digital signature
__
't desirable.
It is also my hope that the packaging on upstream infra will get going.
If it does, it will make more sense to get the Debian guide up to speed,
and probably there will be more contributors.
Cheers,
Thomas Goirand (zigo)
__
On 03/29/2016 11:56 AM, Neil Jerram wrote:
> On 29/03/16 09:38, Thomas Goirand wrote:
>> On 03/23/2016 04:06 PM, Mike Perez wrote:
>>> Hey all,
>>>
>>> I've been talking to a variety of projects about lack of install guides.
>>> This
>>>
prefer
someone else does it, but it's not happening.
So, I'm a bit loss into what should be done to unlock this situation.
I'd like to have directions, and if possible, someone to help with the
Debian guide, at least for testing what has bee
in the mean while,
I'm *very* busy with it).
> We'll also want to make sure we're building packages for trusty and xenial.
All I write works for both. It is fully my intention to support Trusty
and Xenial as well as Jessie and hopefully Sid (with probably Sid as
non-voting, as
g
the patch as distro-specific until it's merged).
So, thanks a lot to robcresswell, itxaka and tsufiev who all worked on
this tricky issue!
Cheers,
Thomas Goirand (zigo)
P.S: On the next following days, I'll work on the Horizon plugins.
Hopefully, their wont be too many DJ1
tly does *not* use the upper-constraints
> pinning in its test suite or installation, so we're vulnerable to, say,
> a python-*client release that's not compatible. I have a patch in the
> works to address this, but it kinda depends on us moving over from
> run_tests.sh to tox,
kports from Sid and also publish them.
That's where we are now. Let's go back to the first step, which is the
CR linked above. Help and comments welcome.
Cheers,
Thomas Goirand (zigo)
__
OpenStack
updated_fmt is None:
...
then the build continues to be reproducible (in Debian at least).
Thanks to anyone who took the time to read until here,
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing
ially by this kind of package that don't upgrade often.
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
On 03/18/2016 09:31 AM, Julien Danjou wrote:
> On Thu, Mar 17 2016, Thomas Goirand wrote:
>
>> We don't have enough of such actions, and we have a way too many
>> dependencies, with many duplicate functionalities too. Just to name a few:
>> - oslo.concurrency vs lo
wouldn't say it this way. To me, they are just tools which makes it
easy for us to stop the duplication madness of the same files.
Have a look:
# apt-file search jquery.js | grep -v doc | wc -l
128
This is 127 bugs which should be fixed currently with the embedded
jquery. I hardly see how one
ckaging + infra. Last time in Tokyo, Clack was nice enough to
not attend the Infra sessions to attend the packaging-deb one. I hope
the same thing will not happen again to someone (else?) from Infra, and
that we can get some (much needed) time with them, so we can discuss the
packaging jobs on infra.
r this project to get going.
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/c
On 03/15/2016 09:35 PM, Hayes, Graham wrote:
> On 15/03/2016 20:29, Thomas Goirand wrote:
> Does the current PTL not have the ability to propose extra-atc's for
> this reason?
>
> Would a solution be for zigo to propose the people active in
> http://anonscm.debian.org/cgit/
h brains, not
machines, therefore, it's ok"
Because *you do* have a choice, don't you?
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev
setup properly with the
Debian image and build infrastructure. I'm aware of it, and I hope we
can fix this during the Newton cycle. Though a lot of teams are waiting
on this project. Puppet OpenStack wants to gate on what we'll be
producing, and so is Fuel. The plan is that MOS g
he other sub-project.
Let's remember the bad releases of setuptools :)
Cheers,
Thomas Goirand (zigo)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@li
y way to get the web app use the JS libs from
the OS, and there's no system wide registry of installed components.
XStatic does that. Get $your-favoring-js-package-manager to do it, just
like php pear, perl CPAN, or Python pip does, then we will adopt it.
This, of course, requires work on ups
101 - 200 of 696 matches
Mail list logo
