On 2015-02-01 00:52:21 +0100 (+0100), Thomas Goirand wrote:
[...]
> Upstream authors decided to remove the sample config files for a
> reason, which is: there's no way to provide a valid sample config
> file because it depends on the version of the installed libs.
[...]
That's sort of true, but mo
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 1/28/15, 4:45 PM, "Mathieu Gagné" wrote:
>On 2015-01-28 6:30 PM, Tom Fifield wrote:
>> On 29/01/15 07:28, Thomas Goirand wrote:
>>> On 01/27/2015 11:00 PM, Tom Fifield wrote:
Hi all,
Based on Gustavo's excellent work below, talking with many ops, and
after a brief chats wit
On 2015-01-28 6:30 PM, Tom Fifield wrote:
On 29/01/15 07:28, Thomas Goirand wrote:
On 01/27/2015 11:00 PM, Tom Fifield wrote:
Hi all,
Based on Gustavo's excellent work below, talking with many ops, and
after a brief chats with Jeremey and a few other TC folks, here's what
I'd propose as an end
On 29/01/15 07:28, Thomas Goirand wrote:
> On 01/27/2015 11:00 PM, Tom Fifield wrote:
>> Hi all,
>>
>> Based on Gustavo's excellent work below, talking with many ops, and
>> after a brief chats with Jeremey and a few other TC folks, here's what
>> I'd propose as an end goal:
>>
>> * A git repositor
On 01/27/2015 11:00 PM, Tom Fifield wrote:
> Hi all,
>
> Based on Gustavo's excellent work below, talking with many ops, and
> after a brief chats with Jeremey and a few other TC folks, here's what
> I'd propose as an end goal:
>
> * A git repository that has raw, sample configs in it for each pr
Yes!
Just had have discussion about this with my colleague yesterday.
Seems be perfect solution.
On 01/28/2015 12:00 AM, Tom Fifield wrote:
Hi all,
Based on Gustavo's excellent work below, talking with many ops, and
after a brief chats with Jeremey and a few other TC folks, here's what
I'd pr
Hi all,
Based on Gustavo's excellent work below, talking with many ops, and
after a brief chats with Jeremey and a few other TC folks, here's what
I'd propose as an end goal:
* A git repository that has raw, sample configs in it for each project
that will be automagically updated
* Raw configs
On 12/18/2014 09:57 AM, Jeremy Stanley wrote:
4. Set up a service that periodically regenerates sample
configuration and tracks it over time. This attempts to address the
stated desire to be able to see how sample configurations change,
but note that this is a somewhat artificial presentation s
On Fri, Dec 19, 2014 at 9:18 AM, Thomas Bechtold wrote:
>
> On 18.12.2014 14:03, Thomas Goirand wrote:
> > Jeremy,
> >
> > Thanks *A LOT* for writing this up. This is very helpful.
> >
> > On 12/18/2014 09:57 AM, Jeremy Stanley wrote:
> >> During the first half of yesterday's cross-project meeting
On 18.12.2014 14:03, Thomas Goirand wrote:
> Jeremy,
>
> Thanks *A LOT* for writing this up. This is very helpful.
>
> On 12/18/2014 09:57 AM, Jeremy Stanley wrote:
>> During the first half of yesterday's cross-project meeting, we went
>> through the sample configuration packaging/publishing topi
Jeremy,
Thanks *A LOT* for writing this up. This is very helpful.
On 12/18/2014 09:57 AM, Jeremy Stanley wrote:
> During the first half of yesterday's cross-project meeting, we went
> through the sample configuration packaging/publishing topic to get a
> better idea of what options are open to us
On 2014-12-18 01:57:20 + (+), Jeremy Stanley wrote:
[...]
> 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.
I meant to add that as an outco
During the first half of yesterday's cross-project meeting, we went
through the sample configuration packaging/publishing topic to get a
better idea of what options are open to us. Many thanks to all who
attended. The meeting summary with a link to the full discussion
logs can be found here:
http:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi George
On 16/12/14 01:38, George Shuklin wrote:
> Can you say why you didn't ship 2013.2.4? It was available in
> announced support lifecycle for cloudarchive, and you just stops to
> do anything with 2013.2.3 (havana) somewhere in the middle of
On 12/16/2014 12:33 AM, Kris G. Lindgren wrote:
> That¹s - great. But other people will want it to be based on RHEL -
> others Ubuntu, some people will want it on SLES. I understand debian
> makes your life easier, but at Paris is was already determined that a one
> size fits all approach wont wo
On 12/16/2014 09:33 AM, George Shuklin wrote:
> Nope. I've only done stuff with debian-jenkins-glue. But I have some
> experience on backporting patches from icehouse to havana (it still in
> production and still need fixes). I can research/fix something specific
> and local.
Oh, if you're good wi
Oh!
Ubuntu's guy.
Can you say why you didn't ship 2013.2.4? It was available in announced
support lifecycle for cloudarchive, and you just stops to do anything
with 2013.2.3 (havana) somewhere in the middle of the summer. It was
really bad, because few important fixes for neutron were landed
On 12/15/2014 10:49 AM, Thomas Goirand wrote:
and ubuntu just put files
in proper places without changing configs.
Ahem... Ubuntu simply doesn't care much about config files. See what
they ship for Nova and Cinder. I wouldn't say "without changing configs"
in this case.
We using chef for
confi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi Thomas
On 15/12/14 08:49, Thomas Goirand wrote:
>> and ubuntu just put files
>>> in proper places without changing configs.
> Ahem... Ubuntu simply doesn't care much about config files. See
> what they ship for Nova and Cinder. I wouldn't say "wi
On 12/13/14, 8:09 AM, "Thomas Goirand" wrote:
>On 12/12/2014 02:17 AM, Kris G. Lindgren wrote:
>>> Why do you think it's a good idea to restart doing the work of
>>> distributions by yourself? Why not joining a common effort?
>>
>> Well for a lot of reasons. Some of us carry our own patch set
On 12/14/2014 06:39 AM, George Shuklin wrote:
> Btw: we talking about debian packages or ubuntu?
Debian, not Ubuntu.
> They are differ -
> debian heavily relies on answers to debconfig
You mean debconf. And no, it doesn't "rely on", it's completely
optional, and the packages *must* be able to be
On 12/14/2014 01:27 AM, Jeremy Stanley wrote:
On 2014-12-14 00:39:41 +0200 (+0200), George Shuklin wrote:
[...]
debian heavily relies on answers to debconfig, and ubuntu just put
files in proper places without changing configs. We using chef for
configuration, so ubuntu approach is better (when
On 2014-12-14 00:39:41 +0200 (+0200), George Shuklin wrote:
[...]
> debian heavily relies on answers to debconfig, and ubuntu just put
> files in proper places without changing configs. We using chef for
> configuration, so ubuntu approach is better (when we starts doing
> openstack that was on of
On 12/13/2014 05:13 PM, Thomas Goirand wrote:
If I can help somehow, I'm ready to do something, but What should I
do, exactly?
There's a lot that can be done. If you like working on CI stuff, then
you could help me with building the package validation CI which I'm
trying to (re-)work. All of
On 2014-12-13 23:16:56 +0800 (+0800), Thomas Goirand wrote:
[...]
> 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" thing
> automatically.
I'll be happy to do
On 2014-12-13 23:13:44 +0800 (+0800), Thomas Goirand wrote:
[...]
> Once we have this, then we could start building a repository with
> everything from trunk. And when that is done, starting the effort of
> building a 3rd party CI to do package validation on the gate.
This sounds like a great idea
On 12/13/2014 04:59 AM, Jeremy Stanley wrote:
> On a related note, this topic has been added to the agenda[1] for
> Tuesday's Cross-Project Meeting (December 16, 21:00 UTC in the
> #openstack-meeting channel on the Freenode IRC network). If you're
> passionate about the issue then please come help
On 12/13/2014 04:30 AM, George Shuklin wrote:
> I do some tiny CI in my company: repackaging ubuntu
> packages with debian-jenkins-glue (plus backported patches
> icehouse->havana)
Ah, that's interesting! :)
> If I can help somehow, I'm ready to do something, but What should I
> do, exactly?
On 12/12/2014 02:17 AM, Kris G. Lindgren wrote:
>> Why do you think it's a good idea to restart doing the work of
>> distributions by yourself? Why not joining a common effort?
>
> Well for a lot of reasons. Some of us carry our own patch sets
My employer (ie: Mirantis) also has its own patch s
On a related note, this topic has been added to the agenda[1] for
Tuesday's Cross-Project Meeting (December 16, 21:00 UTC in the
#openstack-meeting channel on the Freenode IRC network). If you're
passionate about the issue then please come help work out a
consistent solution we can recommend to all
Real hard work, man. Thanks.
I think the problem is that most of ops does not know enough about whole
stuff needed. I do some tiny CI in my company: repackaging ubuntu
packages with debian-jenkins-glue (plus backported patches
icehouse->havana), but I can't say I understand all stuff happens
Example of this @ http://paste.ubuntu.com/9483214/
For those that are interested (and yes I know the conflict resolver
isn't super...)
-Josh
Kris G. Lindgren wrote:
> Anvil figures out the build dependencies for me - it also figures out if
> those deps are satisfiable via yum, if not downloa
Please see inline.
TL;DR - Thanks for the bash script and a kinda round about way of how you
got your configs for Debian. You are missing the point that the packaging
tooling that we want to build - should make your life as a the only
package maintainer for Debian easier.
at 9:38 AM
To: Matt Fischer
mailto:matthew.fisc...@twcable.com>>
Cc: Michael Dorman mailto:mdor...@godaddy.com>>,
"openstack-operators@lists.openstack.org<mailto:openstack-operators@lists.openstack.org>"
mailto:openstack-operators@lists.openstack.org>>
Subje
On Wed, Dec 10, 2014 at 11:16 AM, Fischer, Matt wrote:
>
>
> From: Anne Gentle
> Date: Wednesday, December 10, 2014 at 8:41 AM
> To: Michael Dorman
> Cc: "openstack-operators@lists.openstack.org" <
> openstack-operators@lists.openstack.org>
> Subj
Hi,
FYI, I'm the person behind all Debian packages of OpenStack. I'm working
full-time on packaging OpenStack for Debian, and I've been doing so for
the last few years (I started to get involved in the Cactus release,
which is years ago now...). It's been a long time I wanted to reply to
this thre
ists.openstack.org>>
Subject: Re: [Openstack-operators] Packaging sample config versions
On Tue, Dec 9, 2014 at 11:25 AM, Michael Dorman
mailto:mdor...@godaddy.com>> wrote:
Well I think we can all agree this is an irritation. But how are others
actually dealing with this problem?
On Tue, Dec 9, 2014 at 11:25 AM, Michael Dorman wrote:
> Well I think we can all agree this is an irritation. But how are others
> actually dealing with this problem? (Maybe it’s less complicated in
> Ubuntu.)
>
> The sense I get is that most people using Anvil, or other custom-ish
> packaging
Well I think we can all agree this is an irritation. But how are others
actually dealing with this problem? (Maybe it’s less complicated in
Ubuntu.)
The sense I get is that most people using Anvil, or other custom-ish
packaging tools, are also running config management which handles
generati
So more to my point on the latest version of RHEL and doing: yum install
tox -egenconfig
ceilometer-2014.2.1]# tox -egenconfig
ERROR: tox version is 1.4.2, required is at least 1.6
nova-2014.2.1]# tox -egenconfig
ERROR: tox version is 1.4.2, required is at least 1.6
glance-2014.2.1]# tox -egen
On 2014-12-08 11:01 PM, Kris G. Lindgren wrote:
I don’t think its too much to ask for each project to include a script
that will build a venv that includes tox and the other relevant deps to
build the sample configuration.
This is already the case. Back then, I did the work of documenting ho
com>>
Date: Monday, December 8, 2014 at 8:23 PM
To: "Kris G. Lindgren" mailto:klindg...@godaddy.com>>,
"openstack-operators@lists.openstack.org<mailto:openstack-operators@lists.openstack.org>"
mailto:openstack-operators@lists.openstack.org>>
Subject: Re:
>>
>> I do know that some projects, like nova and cinder, still ship the file.
>
>Cinder I believe just kicked that out (for better or worse),
>
>https://github.com/openstack/cinder/commit/62a72a7574b18f7
>
>One less. I don't think nova does either anymore...
>
Oops I meant keystone! Nova was one
On 2014-12-08 10:23 PM, Fischer, Matt wrote:
I do know that some projects, like nova and cinder, still ship the file.
Nova does not ship the config file anymore:
https://review.openstack.org/#/c/81588/
https://github.com/openstack/nova/blob/master/etc/nova/README-nova.conf.txt
Cinder recentl
Fischer, Matt wrote:
I also find this issue really really annoying. Not only is the sample
config a useful reference, but having it in a git repo allows me to see
when new options were added or defaults were changed. Otherwise you have
to rely on the docs which are generally wrong. When I was loo
I also find this issue really really annoying. Not only is the sample config a
useful reference, but having it in a git repo allows me to see when new options
were added or defaults were changed. Otherwise you have to rely on the docs
which are generally wrong. When I was looking at some of the
47 matches
Mail list logo
