Open Stack

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 view, if clients are regarding all reules there is no compatibility
issues => it is easy to add them to g-r. Am I wrong?


All,

Sorry I wasn't able to be on meeting yesterday.


First of all, we don't have any issues with having Murano/Mistral
benchmarks and testing them in gates and supporting them in our tree. (We
already have rally-dsvm-murano and rally-dsvm-mistral dsvm jobs that works
well)

The real issue is very bad user & dev experience caused by soft decencies.

Let's take a look at actions of typical user (running Murano benchamrk):
1) Try to run tests for Murano
2) Input validation error: MuranoClient is missing please install it
3) WTF???

Let's take a look at actions of end developer (writing Murano benchmark):
1) Try to make new Murano benchmark
2) Need to import some exceptions from Murano client
3) All unit tests are failing..
4) WTF???

Adding extra steps/conditions that are required for using product are
adding exponential complexity to it. So having 5 such steps/conditions will
make product inconsumable.

So the only thing that I would like is to remove one "extra step" by adding
good python clients to g-r.


Best regards,
Boris Pavlovic




On Wed, Jan 21, 2015 at 4:15 AM, Robert Collins <robertc at robertcollins.net>
wrote:

> On 21 January 2015 at 10:21, Clark Boylan <cboylan at 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
> > requirements managed by global requirements.
> >
> > For the project structure reform opening things up we should consider
> > loosening the criteria to get on the list and make it primarily based on
> > technical criteria such as py3k support, license compatibility, upstream
> > support/activity, and so on (basically the current criteria with less of
> > a focus on where the project comes from if it is otherwise healthy).
> > Then individual projects would choose the subset they need to depend on.
> > This model should be viable with different domains as well if we go that
> > route.
> >
> > The following is not from the TC meeting but addressing other portions
> > of this conversation:
> >
> > At least one concern with this option is that as the number of total
> > requirements goes up is the difficulty in debugging installation
> > conflicts becomes more difficult too. I have suggested that we could
> > write tools to help with this. Install bisection based on pip logs for
> > example, but these tools are still theoretical so I may be
> > overestimating their usefulness.
> >
> > To address the community scaling aspect I think you push a lot of work
> > back on deployers/users if we don't curate requirements for anything
> > that ends up tagged as "production ready" (or whatever the equivalent
> > tag becomes). Essentially we are saying "this doesn't scale for us so
> > now you deal with the fallout. Have fun", which isn't very friendly to
> > people consuming the software. We already have an absurd number of
> > requirements and management of them has appeared to scale. I don't
> > foresee my workload going up if we open up the list as suggested.
>
> Perhaps I missed something, but the initial request wasn't about
> random packages, it was about other stackforge clients - these are
> things in the ecosystem! I'm glad we have technical solutions, but it
> just seems odd to me that adding them would ever have been
> controversial.
>
> 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.
>
> -Rob
>
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150121/cf1470b8/attachment.html>