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

Eric Fried openstack at fried.cc
Mon Feb 25 01:25:39 UTC 2019


+1 to combining specs into the code repo.

Re launchpad vs storyboard: This may be going too far, but is "neither" an option? The information in a blueprint has always seemed largely redundant to me. Approved blueprints can be review.o.o?proj=placement&status=merged&path=specs/$release/approved/*. Whiteboards can be etherpads (which is what I thought you were talking about originally, which confused me, because I marked the placement blueprints unblocked on the etherpad last week; didn't think to duplicate that to the blueprints, my bad.) Are etherpads any more... "ethereal" than lp whiteboards or storyboards? (Does anyone look at those after the blueprint is closed?)

Eric Fried
Concept Brazilian Jiu Jitsu
http://taylorbjj.com

> On Feb 24, 2019, at 18:02, Jay Pipes <jaypipes at gmail.com> wrote:
> 
>> On 02/24/2019 06:17 PM, Matt Riedemann wrote:
>> I was updating the status on some nova blueprints in launchpad today and we have 4 placement API blueprints marked as blocked, with one actually in progress now [1].
>> The issue is none of the changes are being reflected back in the whiteboard for the blueprint in launchpad because the changes are made in the extracted placement repo which doesn't have a launchpad project, nor is there anything in storyboard for placement.
>> Right now it's a small thing, but I'm wondering what, if any, plans are in place for tracking blueprints for the extracted placement repo. I'm assuming the answer is storyboard but maybe it hasn't been discussed much yet.
>> [1] https://blueprints.launchpad.net/nova/+spec/alloc-candidates-in-tree
> 
> There was some light discussion about it on IRC a couple weeks ago. I mentioned my preference was to not have a separate specs repo nor use the Launchpad blueprints feature. I'd rather have a "ideas" folder or similar inside the placement repo itself that tracks longer-form proposals in Markdown documents.
> 
> Just my preference, though. Not sure where others stand on this.
> 
> Best,
> -jay
> 




More information about the openstack-discuss mailing list