[Openstack-operators] [nova] Backlog Specs: a way to send requirements to the developer community

2015-11-12 Thread Steve Gordon 
- Original Message -
> From: "John Garbutt" 
> To: maishsk+openst...@maishsk.com

[SNIP]

> On 14 May 2015 at 19:52, Maish Saidel-Keesing  wrote:
> > Can we please have this as a default template and the default way to allow
> > Operators to submit a feature request for EVERY and ALL the OpenStack
> > projects ??
> 
> +1
> 
> Thats exactly how backlog specs came about.
> 
> I ran a cross project session at the last summit to try and
> standardise how all the different projects deal with specs.
> https://etherpad.openstack.org/p/kilo-crossproject-specs
> 
> From that, we agreed to introduce "Backlog" specs to hold ideas and
> problem statements, and un-targeted or un-assigned specs. We intended
> to roughly match what keystone was already doing, although our intent
> appears to have diverged a little.
> 
> This is the first design summit where we have the "concept" in place,
> and I would love your help road testing this.
> 
> If an operator working session agreed on a problem statement, or set
> of problem statements, putting those up as backlog specs reviews would
> be a great way to get feedback from the developer community.
> 
> >> On Thu, May 14, 2015 at 8:47 PM, John Garbutt 
> >>> You can read more about Nova's backlog specs here:
> >>> http://specs.openstack.org/openstack/nova-specs/specs/backlog/
> 
> Let me give more detail. To quote the above page:
> 
> "
> If you have a problem that needs solving, but you are not currently
> planning on implementing it, this is the place we can store your
> ideas.
> These specifications have the problem description completed, but all
> other sections are optional.
> "
> 
> 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.
> 
> With that extra detail, do you think this could work?
> 
> Thanks,
> John

Hi all,

I get the impression from the feedback on a recently submitted item [1] and 
also a read of a clarification that was made to the backlog page [2] that this 
is no longer the way the backlog works? Specifically, a proposed or desired 
solution is now required and the page now talks about it being a place for the 
project team to record decisions only (originally it seemed more focused on 
recording ideas).

>From an NFV/Telco working group perspective we have been trying to convince 
>folks for some time to stop leading with pre-defined solutions and focus more 
>- at least in the first instance - on documenting their use cases in a way 
>that they could be shared with the relevant OpenStack project teams via their 
>respective RFE/backlog processes. It seems to me though based on my 
>experiences having actually tried to submit one of these ideas as a dry run 
>there is not in fact a working process for recording these as originally 
>advertised [3][4][5]? Am I misinterpreting the intent of the change here?

Thanks,

Steve

[1] https://review.openstack.org/#/c/224325/
[2] 
http://git.openstack.org/cgit/openstack/nova-specs/commit/doc/source/specs/backlog/index.rst?id=525af38a5ce27bed70d950234e94a48584820943
[3] 
http://git.openstack.org/cgit/openstack/nova-specs/tree/doc/source/specs/backlog/index.rst?id=41bf5302e7ff2b9305b0e8a459e9fe715fba0c38
[4] http://lists.openstack.org/pipermail/openstack-dev/2015-May/064284.html
[5] http://lists.openstack.org/pipermail/openstack-dev/2015-May/064180.html

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [nova] Backlog Specs: a way to send requirements to the developer community

2015-05-15 Thread Boris Pavlovic 
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  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 h

Re: [Openstack-operators] [nova] Backlog Specs: a way to send requirements to the developer community

2015-05-15 Thread Sean Dague 
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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [nova] Backlog Specs: a way to send requirements to the developer community

2015-05-15 Thread Boris Pavlovic 
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?


Best regards,
Boris Pavlovic


On Fri, May 15, 2015 at 11:46 AM, John Garbutt  wrote:

> > On 05/14/15 21:04, Boris Pavlovic wrote:
> > I believe that backlog should be different much simpler then specs.
>
> Agreed. And they are.
>
> > Imho Operators don't have time / don't want to write long long specs and
> > analyze how they are aligned with specs
> > or moreover how they should be implemented and how they impact
> > performance/security/scalability. They want
> > just to provide feedback and someday get it implemented/fixed.
>
> Working for an operator myself, I agree, thats the idea.
>
> Bugs still go into a bug report.
>
> These backlog specs are for feature requests, like additional APIs, or
> additional configurability, etc. Where you need to have a conversation
> between the operator and the developer communities.
>
> > In Rally we chose different way called "feature request".
> > The process is the same as for specs, but template is much simpler.
>
> I think this is similar.
>
> On 14 May 2015 at 19:52, Maish Saidel-Keesing  wrote:
> > Can we please have this as a default template and the default way to
> allow
> > Operators to submit a feature request for EVERY and ALL the OpenStack
> > projects ??
>
> +1
>
> Thats exactly how backlog specs came about.
>
> I ran a cross project session at the last summit to try and
> standardise how all the different projects deal with specs.
> https://etherpad.openstack.org/p/kilo-crossproject-specs
>
> From that, we agreed to introduce "Backlog" specs to hold ideas and
> problem statements, and un-targeted or un-assigned specs. We intended
> to roughly match what keystone was already doing, although our intent
> appears to have diverged a little.
>
> This is the first design summit where we have the "concept" in place,
> and I would love your help road testing this.
>
> If an operator working session agreed on a problem statement, or set
> of problem statements, putting those up as backlog specs reviews would
> be a great way to get feedback from the developer community.
>
> >> On Thu, May 14, 2015 at 8:47 PM, John Garbutt 
> >>> You can read more about Nova's backlog specs here:
> >>> http://specs.openstack.org/openstack/nova-specs/specs/backlog/
>
> Let me give more detail. To quote the above page:
>
> "
> If you have a problem that needs solving, but you are not currently
> planning on implementing it, this is the place we can store your
> ideas.
> These specifications have the problem description completed, but all
> other sections are optional.
> "
>
> 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.
>
> With that extra detail, do you think this could work?
>
> Thanks,
> John
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [nova] Backlog Specs: a way to send requirements to the developer community

2015-05-15 Thread John Garbutt 
> On 05/14/15 21:04, Boris Pavlovic wrote:
> I believe that backlog should be different much simpler then specs.

Agreed. And they are.

> Imho Operators don't have time / don't want to write long long specs and
> analyze how they are aligned with specs
> or moreover how they should be implemented and how they impact
> performance/security/scalability. They want
> just to provide feedback and someday get it implemented/fixed.

Working for an operator myself, I agree, thats the idea.

Bugs still go into a bug report.

These backlog specs are for feature requests, like additional APIs, or
additional configurability, etc. Where you need to have a conversation
between the operator and the developer communities.

> In Rally we chose different way called "feature request".
> The process is the same as for specs, but template is much simpler.

I think this is similar.

On 14 May 2015 at 19:52, Maish Saidel-Keesing  wrote:
> Can we please have this as a default template and the default way to allow
> Operators to submit a feature request for EVERY and ALL the OpenStack
> projects ??

+1

Thats exactly how backlog specs came about.

I ran a cross project session at the last summit to try and
standardise how all the different projects deal with specs.
https://etherpad.openstack.org/p/kilo-crossproject-specs

>From that, we agreed to introduce "Backlog" specs to hold ideas and
problem statements, and un-targeted or un-assigned specs. We intended
to roughly match what keystone was already doing, although our intent
appears to have diverged a little.

This is the first design summit where we have the "concept" in place,
and I would love your help road testing this.

If an operator working session agreed on a problem statement, or set
of problem statements, putting those up as backlog specs reviews would
be a great way to get feedback from the developer community.

>> On Thu, May 14, 2015 at 8:47 PM, John Garbutt 
>>> You can read more about Nova's backlog specs here:
>>> http://specs.openstack.org/openstack/nova-specs/specs/backlog/

Let me give more detail. To quote the above page:

"
If you have a problem that needs solving, but you are not currently
planning on implementing it, this is the place we can store your
ideas.
These specifications have the problem description completed, but all
other sections are optional.
"

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.

With that extra detail, do you think this could work?

Thanks,
John

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [nova] Backlog Specs: a way to send requirements to the developer community

2015-05-14 Thread Maish Saidel-Keesing 

On 05/14/15 21:04, Boris Pavlovic wrote:

John,

I believe that backlog should be different much simpler then specs.

Imho Operators don't have time / don't want to write long long specs 
and analyze how they are aligned with specs
or moreover how they should be implemented and how they impact 
performance/security/scalability. They want

just to provide feedback and someday get it implemented/fixed.

In Rally we chose different way called "feature request".
The process is the same as for specs, but template is much simpler.

Bravo

Can we please have this as a default template and the default way to 
allow Operators to submit a feature request for EVERY and ALL the 
OpenStack projects ??





Here is the page:
https://rally.readthedocs.org/en/latest/feature_requests.html

And here is the sample of feature request:
https://rally.readthedocs.org/en/latest/feature_request/launch_specific_benchmark.html


Best regards,
Boris Pavlovic

On Thu, May 14, 2015 at 9:03 PM, Boris Pavlovic 
mailto:bpavlo...@mirantis.com>> wrote:


John,

I believe that backlog should be different much simpler then specs.

Imho Operators don't have time / don't want to write long long
specs and analyze how they are aligned with specs
or moreover how they should be implemented and how they impact
performance/security/scalability. They want
just to provide feedback and someday get it implemented/fixed.

In Rally we chose different way called "feature request".
The process is the same as for specs, but template is much simpler.

Here is the page:
https://rally.readthedocs.org/en/latest/feature_requests.html

And here is the sample of feature request:

https://rally.readthedocs.org/en/latest/feature_request/launch_specific_benchmark.html


Best regards,
Boris Pavlovic

On Thu, May 14, 2015 at 8:47 PM, John Garbutt
mailto:j...@johngarbutt.com>> wrote:

Hi,

I was talking with Matt (VW) about how best some large deployment
working sessions could send their requirements to Nova.

As an operator, if you have a problem that needs fixing or use
case
that needs addressing, a great way of raising that issue with the
developer community is a "Backlog" nova-spec.

You can read more about Nova's backlog specs here:
http://specs.openstack.org/openstack/nova-specs/specs/backlog/

Any questions, comments or ideas, please do let me know.

Thanks,
John

PS
In Kilo we formally started accepting "backlog specs",
although we are
only just getting the first of these submitted now. There is
actually
a patch to fix up how they get rendered:
https://review.openstack.org/#/c/182793/2

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators





___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


--
Best Regards,
Maish Saidel-Keesing
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [nova] Backlog Specs: a way to send requirements to the developer community

2015-05-14 Thread Assaf Muller 
Kyle Mestery recently merged a governance change in Neutron that introduces
the idea of request for enhancement bug. Anyone can file a bug against Neutron
and tag it with 'rfe'. The bug should include the problem statement and use 
cases,
and any developer can later come in write a spec should it require one.

I encourage the Nova community to adopt the same process.

- Original Message -
> John,
> 
> I believe that backlog should be different much simpler then specs.
> 
> Imho Operators don't have time / don't want to write long long specs and
> analyze how they are aligned with specs
> or moreover how they should be implemented and how they impact
> performance/security/scalability. They want
> just to provide feedback and someday get it implemented/fixed.
> 
> In Rally we chose different way called "feature request".
> The process is the same as for specs, but template is much simpler.
> 
> Here is the page:
> https://rally.readthedocs.org/en/latest/feature_requests.html
> 
> And here is the sample of feature request:
> https://rally.readthedocs.org/en/latest/feature_request/launch_specific_benchmark.html
> 
> 
> Best regards,
> Boris Pavlovic
> 
> On Thu, May 14, 2015 at 9:03 PM, Boris Pavlovic < bpavlo...@mirantis.com >
> wrote:
> 
> 
> 
> John,
> 
> I believe that backlog should be different much simpler then specs.
> 
> Imho Operators don't have time / don't want to write long long specs and
> analyze how they are aligned with specs
> or moreover how they should be implemented and how they impact
> performance/security/scalability. They want
> just to provide feedback and someday get it implemented/fixed.
> 
> In Rally we chose different way called "feature request".
> The process is the same as for specs, but template is much simpler.
> 
> Here is the page:
> https://rally.readthedocs.org/en/latest/feature_requests.html
> 
> And here is the sample of feature request:
> https://rally.readthedocs.org/en/latest/feature_request/launch_specific_benchmark.html
> 
> 
> Best regards,
> Boris Pavlovic
> 
> On Thu, May 14, 2015 at 8:47 PM, John Garbutt < j...@johngarbutt.com > wrote:
> 
> 
> Hi,
> 
> I was talking with Matt (VW) about how best some large deployment
> working sessions could send their requirements to Nova.
> 
> As an operator, if you have a problem that needs fixing or use case
> that needs addressing, a great way of raising that issue with the
> developer community is a "Backlog" nova-spec.
> 
> You can read more about Nova's backlog specs here:
> http://specs.openstack.org/openstack/nova-specs/specs/backlog/
> 
> Any questions, comments or ideas, please do let me know.
> 
> Thanks,
> John
> 
> PS
> In Kilo we formally started accepting "backlog specs", although we are
> only just getting the first of these submitted now. There is actually
> a patch to fix up how they get rendered:
> https://review.openstack.org/#/c/182793/2
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> 
> 
> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [nova] Backlog Specs: a way to send requirements to the developer community

2015-05-14 Thread Boris Pavlovic 
John,

I believe that backlog should be different much simpler then specs.

Imho Operators don't have time / don't want to write long long specs and
analyze how they are aligned with specs
or moreover how they should be implemented and how they impact
performance/security/scalability. They want
just to provide feedback and someday get it implemented/fixed.

In Rally we chose different way called "feature request".
The process is the same as for specs, but template is much simpler.

Here is the page:
 https://rally.readthedocs.org/en/latest/feature_requests.html

And here is the sample of feature request:
https://rally.readthedocs.org/en/latest/feature_request/launch_specific_benchmark.html



Best regards,
Boris Pavlovic

On Thu, May 14, 2015 at 9:03 PM, Boris Pavlovic 
wrote:

> John,
>
> I believe that backlog should be different much simpler then specs.
>
> Imho Operators don't have time / don't want to write long long specs and
> analyze how they are aligned with specs
> or moreover how they should be implemented and how they impact
> performance/security/scalability. They want
> just to provide feedback and someday get it implemented/fixed.
>
> In Rally we chose different way called "feature request".
> The process is the same as for specs, but template is much simpler.
>
> Here is the page:
>  https://rally.readthedocs.org/en/latest/feature_requests.html
>
> And here is the sample of feature request:
>
> https://rally.readthedocs.org/en/latest/feature_request/launch_specific_benchmark.html
>
>
>
> Best regards,
> Boris Pavlovic
>
> On Thu, May 14, 2015 at 8:47 PM, John Garbutt 
> wrote:
>
>> Hi,
>>
>> I was talking with Matt (VW) about how best some large deployment
>> working sessions could send their requirements to Nova.
>>
>> As an operator, if you have a problem that needs fixing or use case
>> that needs addressing, a great way of raising that issue with the
>> developer community is a "Backlog" nova-spec.
>>
>> You can read more about Nova's backlog specs here:
>> http://specs.openstack.org/openstack/nova-specs/specs/backlog/
>>
>> Any questions, comments or ideas, please do let me know.
>>
>> Thanks,
>> John
>>
>> PS
>> In Kilo we formally started accepting "backlog specs", although we are
>> only just getting the first of these submitted now. There is actually
>> a patch to fix up how they get rendered:
>> https://review.openstack.org/#/c/182793/2
>>
>> ___
>> OpenStack-operators mailing list
>> OpenStack-operators@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

[Openstack-operators] [nova] Backlog Specs: a way to send requirements to the developer community

2015-05-14 Thread John Garbutt 
Hi,

I was talking with Matt (VW) about how best some large deployment
working sessions could send their requirements to Nova.

As an operator, if you have a problem that needs fixing or use case
that needs addressing, a great way of raising that issue with the
developer community is a "Backlog" nova-spec.

You can read more about Nova's backlog specs here:
http://specs.openstack.org/openstack/nova-specs/specs/backlog/

Any questions, comments or ideas, please do let me know.

Thanks,
John

PS
In Kilo we formally started accepting "backlog specs", although we are
only just getting the first of these submitted now. There is actually
a patch to fix up how they get rendered:
https://review.openstack.org/#/c/182793/2

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators