Open Stack

Sean,

Adding most features to most projects requires a reasonable conversation
> about how that impacts other parts of that project, and other projects
> in OpenStack, and how it impacts existing deploys of OpenStack, and
> compatibility between OpenStack implementations in the field, especially
> as we try to get more serious about interoperability.


Agree on this but this work should be done by team NOT end users.
End users should say: "I like it or not and why" or something is missing
they don't care how this is going to be implemented.


I get that everyone wants an easy button, and for magical elves to do
> stuff. However I think Rally is the anomaly here, as it doesn't need to
> address many of these concerns for where it lives in the tools stack.


Believe me Rally is the same project as others. We have the same problems
like other OpenStack projects.

Some of feature request that sound quite easy (Support of benchmarking with
existing
users) required a lot of work and discussion inside the Rally team, and no
one from users
or even developers were able to write proper spec 1 year ago..



> And easy process for submit, that ends up with too little information or
> engagement to be useful, is worse than none at all. Because then there
> is just a black hole in the middle where everything is going to get lost.


Users should have simple as possible way to provide simple feed back.
That should be analyzed by core team and PTL and transferred to real specs.
For example:

- "I need to have automated no downtime upgrades from one version to
another.
   Because otherwise I can't use OpenStack in production"

- "Tenant deletion should remove, because it's not clear how to delete all
resources by hands".

- "I would like to have restorable resources. Users that deleted by
accident resources like VM, should be
able to restore them during some fixed amount of time like 5 minutes."

It's impossible hard task to create proper spec but it's super simple to
provide such feature request.


Best regards,
Boris Pavlovic


On Fri, May 15, 2015 at 2:38 PM, Sean Dague <sean at dague.net> wrote:

> On 05/15/2015 07:20 AM, Boris Pavlovic wrote:
> > John,
> >
> >
> >     So, you can have all details in the spec, or you can have only the
> >     problem statement complete. Its up to you as a submitter how much
> >     detail you want to provide. I would recommend adding rough ideas into
> >     the alternatives section, and leaving everything else blank except
> the
> >     problem statement.
> >
> >
> >      We are trying to use a single process for "parked" developer ideas
> and
> >     operator ideas, so they are on an equal footing.
> >     The reason its not just a "bug" or similar, is so we are able to
> >     review the idea with the submitter, to ensure we have a good enough
> >     problem description, so a developer can pick up and run with the
> idea,
> >     and turn it into a more complete spec targeted at a specific release.
> >     In addition, we are ensuring that the problem description is in
> scope.
> >
> >
> > Feature requests are the same process as specs. And I fully agree
> > that bug reports are not good idea for this.
> >
> > The only difference is template. I believe you won't find end users
> > that would like to spend time to read all this steps:
> > http://specs.openstack.org/openstack/nova-specs/specs/kilo/template.html
> > and provide required info.
> >
> > As an end users I would like to spend maximum 5 minutes to provide info
> > about:
> > - use case
> > - problem description
> > - possible solution [optional]
> >
> >
> > What about making nova template simpler?
> > And actually doing this across all projects?
>
> So... "maximum 5 minutes" is where I think that idea goes horribly off
> the rails. Because it actually sets up the *wrong* expectations of how
> we make progress as a community, and is only going to cause anger and
> frustration by all parties.
>
> Adding most features to most projects requires a reasonable conversation
> about how that impacts other parts of that project, and other projects
> in OpenStack, and how it impacts existing deploys of OpenStack, and
> compatibility between OpenStack implementations in the field, especially
> as we try to get more serious about interoperability.
>
> I get that everyone wants an easy button, and for magical elves to do
> stuff. However I think Rally is the anomaly here, as it doesn't need to
> address many of these concerns for where it lives in the tools stack.
>
> And easy process for submit, that ends up with too little information or
> engagement to be useful, is worse than none at all. Because then there
> is just a black hole in the middle where everything is going to get lost.
>
> We make progress as a community by building strong communication ties
> across different points of views, reaching out across processes, and
> being willing, on all parts, to invest time to move things forward
> together. It's one of the reasons I think the Ops meetups have been very
> successful, as they provide really great forums to do that.
>
> We don't do it with a max 5 minute submit process.
>
>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150515/c2c90c8c/attachment.html>