[placement][nova] What is the plan for tracking placement blueprints post-extraction?

Sean Mooney smooney at redhat.com
Mon Feb 25 15:55:41 UTC 2019


On Mon, 2019-02-25 at 09:25 -0600, Matt Riedemann wrote:
> On 2/25/2019 5:53 AM, Chris Dent wrote:
> > So, to take it back to Matt's question, my opinion is: Let's let
> > existing stuff run its course to the end of the cycle, decide
> > together how and when we want to implement storyboard.
> 
> FWIW I agree with this. I'm fine with no separate specs repo or core 
> team. I do, however, think that having some tracking tool is important 
> for project management to get an idea of what is approved for a release 
> and what is left (and what was completed). Etherpads are not kanban 
> boards nor are they indexed by search engines so they are fine for notes 
> and such but not great for long-term documentation or tracking.
for what its worth i would proably jsut creat a specs folder in the placement
repo and then choose to use it as much or as little as required.
kolla-ansible for example has an in repo specs folder but it only uses it very
sparingly so the presence of a spec folder does not mean you have to use it
for every feature. they use rfe bugs/blueprint to track most features and
you could make the decision on that later depening on what tool suits placment
best. be that lauchpad,storyboard or just etherpad. etherpad i think make more
sense for tracking review priorites rather then completion but

for what its worth os-vif
does have its own launchpad add we just use RFE bugs for any non cross project features.
for cross project stuff e.g. nova usecases we use a nova bug/blueprint/sepc.
the donwside of this is ironic approved a spec after m2 for a feature this release that required a
os-vif change and we didnt know about it so we had to review it quickly not to block them.
in that case i would have prefered at least an rfe bug against os-vif to tacked the change.

anyway that is just my 2 cents
out of tree specs repos with a sepreate specs core team has its uses but its
overkill i
think in most cases espcially for small repos like placement or os-vif
but haveing a placemnt spec dir might be helpful
in some cases.
> 




More information about the openstack-discuss mailing list