Open Stack

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