On Wed, Jan 21, 2015 at 5:03 AM, Sean Dague s...@dague.net wrote:
On 01/20/2015 08:15 PM, Robert Collins wrote:
On 21 January 2015 at 10:21, Clark Boylan cboy...@sapwetik.org wrote:
...
This ml thread came up in the TC meeting today and I am responding here
to catch the thread up with
TripleO has done per service venvs for a couple years now, and it
doesn't solve the fragility issue that our unbounded deps cause. It
avoids most but not all conflicting deps within OpenStack, and none of
the 'upstream broke us' cases.
-Rob
On 27 January 2015 at 09:01, Joe Gordon
On 01/26/2015 02:29 PM, Robert Collins wrote:
TripleO has done per service venvs for a couple years now, and it
doesn't solve the fragility issue that our unbounded deps cause. It
avoids most but not all conflicting deps within OpenStack, and none of
the 'upstream broke us' cases.
Note that
On 27 January 2015 at 09:56, Clint Byrum cl...@fewbar.com wrote:
moved post to bottom for us backwards folk who see the quotes in
original order
/pedant
TripleO has done per service venvs for a couple years now, and it
doesn't solve the fragility issue that our unbounded deps cause. It
On Tue, 27 Jan 2015, Robert Collins wrote:
Yes, but the experience we have about the limitations of per-service
venvs is still relevant, no? Are you really saying 'do per-service
venvs because they work well', or are you agreeing with me that they
don't solve the problems plaguing the gate?
Excerpts from Robert Collins's message of 2015-01-26 12:29:37 -0800:
On 27 January 2015 at 09:01, Joe Gordon joe.gord...@gmail.com wrote:
On Wed, Jan 21, 2015 at 5:03 AM, Sean Dague s...@dague.net wrote:
On 01/20/2015 08:15 PM, Robert Collins wrote:
On 21 January 2015 at 10:21, Clark
On 22 January 2015 at 02:48, Chris Dent chd...@redhat.com wrote:
On Wed, 21 Jan 2015, Sean Dague wrote:
On the pip solver side, joe gordon was working on a thing to install a
fixed set of packages by bypassing the pip resolver... not sure how
thats progressing.
I think if we are talking
Clarkb,
As Robert said, you are missing the point.
I didn't say that Rally wants this lib so it should be in global
requirements.
I asked only about python clients of stackforge projects that are regarding
all rules:
(Like py3k support, license, are in projects.txt and so on). From my point
of
On 01/20/2015 08:15 PM, Robert Collins wrote:
On 21 January 2015 at 10:21, Clark Boylan cboy...@sapwetik.org wrote:
...
This ml thread came up in the TC meeting today and I am responding here
to catch the thread up with the meeting. The soft update option is the
suggested fix for non
On Wed, 21 Jan 2015, Sean Dague wrote:
On the pip solver side, joe gordon was working on a thing to install a
fixed set of packages by bypassing the pip resolver... not sure how
thats progressing.
I think if we are talking seriously about bypassing the pip resolver, we
should step back and
On Wed, Jan 14, 2015, at 04:50 AM, Sean Dague wrote:
On 01/14/2015 03:55 AM, Flavio Percoco wrote:
On 13/01/15 14:31 -0500, Sean Dague wrote:
On 01/13/2015 02:10 PM, Jay Pipes wrote:
On 01/13/2015 12:39 PM, Zane Bitter wrote:
On 13/01/15 10:01, Jeremy Stanley wrote:
On 2015-01-13
On 21 January 2015 at 10:21, Clark Boylan cboy...@sapwetik.org wrote:
...
This ml thread came up in the TC meeting today and I am responding here
to catch the thread up with the meeting. The soft update option is the
suggested fix for non openstack projects that want to have most of their
On 13/01/15 14:31 -0500, Sean Dague wrote:
On 01/13/2015 02:10 PM, Jay Pipes wrote:
On 01/13/2015 12:39 PM, Zane Bitter wrote:
On 13/01/15 10:01, Jeremy Stanley wrote:
On 2015-01-13 07:46:38 -0500 (-0500), Sean Dague wrote:
Why doesn't rally just remove itself from projects.txt, then there
On 01/14/2015 03:55 AM, Flavio Percoco wrote:
On 13/01/15 14:31 -0500, Sean Dague wrote:
On 01/13/2015 02:10 PM, Jay Pipes wrote:
On 01/13/2015 12:39 PM, Zane Bitter wrote:
On 13/01/15 10:01, Jeremy Stanley wrote:
On 2015-01-13 07:46:38 -0500 (-0500), Sean Dague wrote:
Why doesn't rally just
Flavio,
fyi, nova-docker is aspiring to be part of nova tree itself, but we
had a couple of python libraries we needed for docker that are not in
global, so we used the soft requirements to do that.
https://github.com/stackforge/nova-docker/blob/master/contrib/devstack/gate_hook.sh#L16
thanks,
On 13/01/15 10:01, Jeremy Stanley wrote:
On 2015-01-13 07:46:38 -0500 (-0500), Sean Dague wrote:
Why doesn't rally just remove itself from projects.txt, then there
would be no restrictions on what it adds.
I second this recommendation. If Rally wants to depend on things
which are not part of
On 01/13/2015 02:10 PM, Jay Pipes wrote:
On 01/13/2015 12:39 PM, Zane Bitter wrote:
On 13/01/15 10:01, Jeremy Stanley wrote:
On 2015-01-13 07:46:38 -0500 (-0500), Sean Dague wrote:
Why doesn't rally just remove itself from projects.txt, then there
would be no restrictions on what it adds.
I
On 01/13/2015 12:39 PM, Zane Bitter wrote:
On 13/01/15 10:01, Jeremy Stanley wrote:
On 2015-01-13 07:46:38 -0500 (-0500), Sean Dague wrote:
Why doesn't rally just remove itself from projects.txt, then there
would be no restrictions on what it adds.
I second this recommendation. If Rally
I support this, it will help to not break compatibility with
global-requirements for sole purpose to include python client for other
stackforge project.
On Tue, Jan 13, 2015 at 12:14 AM, Boris Pavlovic bo...@pavlovic.me wrote:
Hello TC,
I would like to propose to allow adding all
On 13/01/15 01:14 +0400, Boris Pavlovic wrote:
Hello TC,
I would like to propose to allow adding all python-clients from stackforge
(that are regarding global-requirements) to global requirements.
I believe this is not a thing for the TC to decided but the dev
community, especially the
Flavio,
Current 2 python clients are Mistral and Murano that I would like to use in
Rally.
I can't add them to requirements = so I need to work everywhere in
lazy-mode + print exceptions to end users
e.g. you don't have this client, so install it - which is really not user
friendly.
Best
On 01/13/2015 06:56 AM, Boris Pavlovic wrote:
Flavio,
Current 2 python clients are Mistral and Murano that I would like to use
in Rally.
I can't add them to requirements = so I need to work everywhere in
lazy-mode + print exceptions to end users
e.g. you don't have this client, so
On 2015-01-13 07:46:38 -0500 (-0500), Sean Dague wrote:
Why doesn't rally just remove itself from projects.txt, then there
would be no restrictions on what it adds.
I second this recommendation. If Rally wants to depend on things
which are not part of OpenStack and not required to run or test
Jeremy, Sean,
First of all because I would like to make a Rally official part of
OpenStack and if I remove
Rally from project.txt this won't happen.
On other side I would like to make OpenStack better. And OpenStack includes
as well
projects on StackForge. That for some reason were rejected. In
On 2015-01-13 19:53:28 +0400 (+0400), Boris Pavlovic wrote:
[...]
P.S. It's sad that in one thread we are talking about making Big
Tenant and how it is cool to remove programs. In another we are
blocking adding python clients from projects that are not Core
and suggesting another making
Hello TC,
I would like to propose to allow adding all python-clients from stackforge
(that are regarding global-requirements) to global requirements.
It doesn't cost anything and simplifies life for everybody on stackforge.
P.S. We already have billions libs in global requirements that aren't
26 matches
Mail list logo
