Open Stack

Hi Jean-Daniel,

I believe this might partially depend on the impact and scope of what is being asked for... 

Here is my personal take on the topic:

#1 If the "feature" you would like to see fits within the scope/functionality of a single project (e.g. nova, neutron, etc.) then I would suggest going through the existing process (whether it's specs, blueprints, or both).

#2 If the "feature" might encounter resistance or might be beneficial to a special interest group (such as enterprise, telco, HPC, etc.). I would still recommend option #1 but you might want to participate in the group with common interest as yours and submit a "use case" to that group so they can track it and possibly help you build further support for the idea.

#3 If the "feature" requires implementation across multiple projects (e.g you might need a blueprint/spec in Nova AND blueprint/RFE in neutron) then writing a "use case" and getting the various blueprints/specs/RFEs tied to it might help from a tracking perspective on whether the holistic capability is implemented

#4 If the "feature" aligns with a known area with multiple parties pursuing it (e.g. logging enhancement, large deployment support, etc.) then I would recommend joining that group and submitting/discussing the idea in that forum so it can be consolidated with other people with the same interest.

Overall, the use case submission is not meant to be repetitive process.  It is required for more complex (complex meaning coordination, effort, scope, etc) ideas so that it can be used to generate multiple blueprints/specs/RFEs to achieve the overall intention.  I think, to a certain aspect, some specs already require a high-level use case too.

Thanks,
Shamail 


> On Jun 5, 2015, at 12:47 PM, Jean-Daniel Bonnetot <jean-daniel.bonnetot at ovhnet> wrote:
> 
> hmm…
> In a perfect world I agree with you.
> In reality, it’s more complex.
> 
> Blueprint, currently, are the *What that need to be done*.
> And specs are the *What* + *How*.
> 
> Here is an example
> BP: https://blueprints.launchpad.net/nova/+spec/flavor-resize-restriction
> Specs: https://review.openstack.org/#/c/182345/
> 
> The *use case* is really well explained in the specs (where you can find the *How* too) and the blueprint give a good idea of *What that need to be done*.
> To give you a use case, I can’t say more that you can already read in the specs in the 36 first lines.
> 
> --
> Jean-Daniel
> @pilgrimstack
> 
> 
> 
> 
>> Le 5 juin 2015 à 16:28, Haselmaier, James <James.Haselmaier at emc.com> a écrit :
>> 
>> I havenąt had a great amount of exposure to Blueprints, but with some
>> quick scanning my take:
>> 
>> Use Cases should focus on the łWhat˛ that needs to be done.  They should
>> document the desired outcome and establish clear context and background as
>> to why that is needed.  The Blueprint should reflect a specific
>> implementation of how that łWhat˛ will be solved.  The Blueprint documents
>> the łHow˛ - the technical details of what will actually be done in the
>> code/system in order to accomplish addressing the Use Case.  If a Use Case
>> is written well (IMHO) there might be a variety of ways to solve it.
>> (I.e. If a łUse Case˛ is written such that it specifies how a sw eng is to
>> implement it then itąs not a use case.)  It becomes the project teamąs
>> area of expertise to decide which implementation works the best -
>> factoring in a variety of factors.  There also may be situations where it
>> takes multiple Blueprints to solve a single Use Case.
>> 
>> In a perfect world the Blueprint might contain a link to the Use Case that
>> is the basis of the Blueprint.  Similarly the Use Case might contain a
>> link to the Blueprint(s) that are being implemented to address the Use
>> Case.  But, frankly, for the progress we need to make with the Product WG
>> at this stage, Iąd propose we put that linking between Use Cases and
>> Blueprints as something we work on down the road.
>> 
>> Jim
>> 
>> On 6/5/15, 7:16 AM, "Jean-Daniel Bonnetot" <jean-daniel.bonnetot at ovh.net>
>> wrote:
>> 
>>> Hi all,
>>> 
>>> Good to see your work. I have some questions.
>>> I already summit some blueprint and spec.
>>> Do I have to write a use case in addition?
>>> How to be efficient and not multiplying same content?
>>> 
>>> https://drive.google.com/folderview?id=0BxtM4AiszlEyfllFelZYR2RqNDFfWVRvWW
>>> tlb09laGxwR2ljc3UxVEl5VEpfMEhicnlxUFk&usp=sharing
>>> 
>>> --
>>> Jean-Daniel Bonnetot
>>> http://www.ovh.com
>>> @pilgrimstack
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Product-wg mailing list
>>> Product-wg at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
> 
> 
> _______________________________________________
> Product-wg mailing list
> Product-wg at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg