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?
To
On 27 January 2015 at 09:56, Clint Byrum wrote:
> original order>
>> 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 'upstr
Excerpts from Robert Collins's message of 2015-01-26 12:29:37 -0800:
> On 27 January 2015 at 09:01, Joe Gordon wrote:
> >
> >
> > On Wed, Jan 21, 2015 at 5:03 AM, Sean Dague wrote:
> >>
> >> On 01/20/2015 08:15 PM, Robert Collins wrote:
> >> > On 21 January 2015 at 10:21, Clark Boylan wrote:
> >
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 th
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 wrote:
>
>
> On
On Wed, Jan 21, 2015 at 5:03 AM, Sean Dague wrote:
> On 01/20/2015 08:15 PM, Robert Collins wrote:
> > On 21 January 2015 at 10:21, Clark Boylan 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 upda
On 22 January 2015 at 02:48, Chris Dent 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 s
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 thin
On 01/20/2015 08:15 PM, Robert Collins wrote:
> On 21 January 2015 at 10:21, Clark Boylan 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 th
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
o
On 21 January 2015 at 10:21, Clark Boylan 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
> requirements managed
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:
> >
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 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:
>> Wh
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
wo
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
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 wants
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 O
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 i
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 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
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
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 regar
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 infra
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 wrote:
> Hello TC,
>
> I would like to propose to allow adding all python-clients from stackfo
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 ev
26 matches
Mail list logo