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
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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
.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
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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
using this architecture: I only checked that
all packages were available.
Cheers,
Thomas Goirand (zigo)
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
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
___
OpenStack-op
On 03/01/2016 11:30 PM, Tom Fifield wrote:
> Excellent, excellent.
>
> What's the best place to buy Raspberry Pis these days?
One of the 2 official sites:
https://www.element14.com/community/community/raspberry-pi
The Pi 3 is the super nice shiny new stuff, with 64 arm bits.
C
h.
> Thanks.
Magnum is in both Debian Sid (version 1.0.0~b1, and it's been months
it's there...) and Experimental (version 1.1.0, aimed at Mitaka). So
it's just an apt-get install away... :)
So far, I had zero feedback from users. Please be my guess, and let me
know what works and
ry helpful to
help me fix a few things. Thanks to anyone who helped closing bugs I've
opened. I'm sure I am forgetting many people who helped a lot.
No keyboard (or any other hardware) was hurt doing this release.
Cheers,
Thomas Goirand (zigo)
[1] If you don't know what I'm talkin
ndling is completely optional, and most of the
helpers are completely disabled by default. So it is *not* in the way of
using any deployment tool like puppet.
Cheers,
Thomas Goirand (zigo)
___
OpenStack-operators mailing list
OpenStack-operators@li
but ("Core") OpenStack
> services have historically been tightly bound to Eventlet for it's
> native-ish threading support. As Keystone has broken free, you are then
> free to deploy our generic WSGI app/s using any generic WSGI server in
> any process / threading architec
ad as an
HTTP server, can't we use anything else written in Python? Isn't it
possible to write a decent HTTP server in Python? Why are we forced into
just Eventlet for doing the job? I haven't searched around, but there
must be loads of alternatives, no?
Cheers,
Thomas Goirand (zi
than happy to get
feedback from you guys, and see how we can improve things to make your
lives easier.
Cheers,
Thomas Goirand (zigo)
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailma
mber of
bugs within the Debian tracker [2]. I've raised the issue multiple times
on the blueprint, but I basically got ignored.
If we want this blueprint to get through, please take into account
remarks that reviewers are making.
Cheers,
Thomas Goirand (zigo)
[1]
https://qa.debian.org/develo
's been some attempts to work more on the dependency
packages together, but mostly, these attempts failed (partly due to the
fact that Canonical insists on using BZR as a VCS). I've seen some bugs
opened with patches by Ubuntu people to lessen the differences for these
packages which is a
with me, and I'll be happy to help you to help.
Bug report
==
If you see any issue in the packages, please do report them to the
Debian bug tracker. Instructions are available here:
https://www.debian.org/Bugs/Reporting
Happy installation,
Thomas Goirand (zigo)
___
On 01/29/2015 12:30 AM, Tom Fifield wrote:
> Actually, many folks I spoke to didn't really care about this.
(computer) science isn't about voting.
On 01/29/2015 01:55 AM, Fischer, Matt wrote:
> Agreed completely. I know it wpn¹t be 100% perfect, but its 95% and
> right now I have 0%.
5% is enoug
On 12/20/2014 11:16 PM, George Shuklin wrote:
> do 'network node on compute' is kinda sad
Why?
Thomas
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
common (ie: oslo-incubator, like it can be seen in
the heat for Kilo beta 1), and that's the thing we shall try to kill
before the final version of Kilo is out.
Cheers,
Thomas Goirand (zigo)
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
On 01/28/2015 09:38 PM, Tim Bell wrote:
> I would therefore propose that the new EC2 API modules are validated in
> production and at scale before depreciating the existing functions. I think
> validating, packaging and deploying to a reasonable number of clouds and
> reviewing it with the opera
l be focused there.
I'd be happy to provide a Debian package for this, however, there's not
even a single git tag there. That's not so nice for tracking issues.
Who's working on it?
Also, is this supposed to be branch-less? Or will it follow juno/kilo/l...
ssue.
> Anyway, this is just an attempt to level-set and spur the discussion
> onward to actionable solutions rather than continuing to debate in
> the abstract. Hopefully it takes us in a good direction.
Let's just hope we'll experience consistency.
Thomas Goirand (zigo)
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> Honestly - I have no preference on this. I am going to change the
> defaults anyway to customize it to something that works for me. So either
> way I need to modify the config file and the configuration management
> stuff does this for me. So if people want to put extra work into making a
> config file that they think is going to work well with everyone please do
> so, to me I think that¹s a dead end. What I would rather see is feedback
> from operators to dev to get some defaults changed to more reasonable
> values. I am specifically thinking about certain periodic tasks that
> everyone after a certain size is either changing or turning off.
I'd love to see this kind of change pushed upstream, so that everyone
has the benefits of it.
Cheers,
Thomas Goirand (zigo)
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
m for just *any* packaging work. From the smallest
Python module, to backporting key packages (like libvirt, Qemu, Ceph,
and so on...), or even working on core packages and testing. Just take
your pick... Basically, I'd accept *any* help, and I will adapt to make
it comfy for you
t-get install
and the Debian packages are all non-interactive as well.
> Anyway, I'm ready to help but have no idea how (within my limits).
Do you have any experience building 3rd party CIs on OpenStack infra?
Thomas Goirand (zigo)
___
Ope
in the Chinese
timezone until the 29th of this month.
Therefore, could you please forward my thought on the meeting, which is:
python setup.py install/sdist should be running the
"tools/config/generate_sample.sh -b . -p nova -o etc/nova&
from trunk. And when that is done, starting the effort of
building a 3rd party CI to do package validation on the gate.
Your thoughts?
Cheers,
Thomas Goirand (zigo)
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
gt;>> script that will build a venv that includes tox and the other
>>> relevant deps to build the sample configuration.
>>
>> A venv, seriously?!?
>>
>> No, it's not that. What need to happen is to have an easy and *OpenStack
>> unified
CRAP! And as a package maintainer,
I strongly believe that it's my duty to make packages at least a little
bit useable by default.
> Is that accurate for most people? Or are folks doing some other
> magic to get a good config file in the packages?
No magic. Only hard work can make it
31 matches
Mail list logo
