Open Stack

On Fri, Apr 18, 2014 at 10:51 AM, Scott Devoid <devoid at anl.gov> wrote:

> The issue is that it is very easy to suggest new features and refactoring
> when you are very familiar with the codebase. To a newcomer, though, you
> are basically asking me to do something that is impossible, so the logical
> interpretation is you're telling me to "go away".
>

This patch was dropped on us twice without any conversation or warning or
discussion about how might be the best approach. Suggestions _were_ made
and subsequently ignored.  If there was a lack of understanding, asking
questions is a good way to get past that.  None were asked.  I do not view
that as saying 'go away'.

The plugin mechanism is designed to facillitate these sort of additions.
 They can be completely drop-in, at minimum one file in extras.d and config
in local.conf.  The question is about the additional modifications required
to the base DevStack scripts.  We can address if anyone can articulate what
is not possible with the existing setup.  At this point I do not know what
those needs are, nobody has contacted me directly to talk about any of this
outside drive-by Gerrit review comments.  That is not the place for a
design discussion.

I see your motivations here. There are systems to help us with this though:
> redirect them to ask.openstack.org or bugs.launchpad.net and have them
> ping you with the link. Delegate replies to others. I try to answer any
> questions that pop up on #openstack but I need to look at the
> ask.openstack.org queue more often. Perhaps we need to put more focus on
> organizing community support and offloading that task from PTLs and core
> devs.
>

DevStack is an _opinionated_ OpenStack installer.  It can not and will not
be all things to all people.  The first priority is to address services
required by OpenStack projects (database, queue, web server, etc) and even
then we only use what is provided in the underlying distributions.  (BTW,
does zmq even still work?  I don't think it is tested.)

Layered products that require 3rd party repos have a higher bar to get over
to be included in the DevStack repo.  If an OpenStack project changes to
require such a product, and that change gets through the TC (see MongoDB
discussions for an example), then we'll have to re-evaluate that position.

All this said, I really do want to see Ceph support for Cinder, Glance,
Swift, etc in DevStack as I think it is cool and useful.  But it is not
required to be in the DevStack repo to be useful.

Chmouel has proposed a session on this subject and it is likely to be
accepted as there are no other submissions for the last slot.

dt

-- 

Dean Troyer
dtroyer at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140418/9d2a4964/attachment.html>