[openstack-dev] [tripleo] storyboard evaluation
fungi at yuggoth.org
Tue Jan 16 16:29:32 UTC 2018
On 2018-01-16 06:55:03 -0800 (-0800), Emilien Macchi wrote:
> I created a dev instance of storyboard and imported all bugs from
> TripleO so we could have a look at how it would be if we were using
> the tool:
Awesome! We do also have a https://storyboard-dev.openstack.org/
deployment we can do test migrations into if you'd prefer something
more central with which to play around.
> - how do we deal milestones in stories and also how can we have a
> dashboard with an overview per milestone (useful for PTL + TripleO
> release managers).
So far, the general suggestion for stuff like this is to settle on a
consistent set of story tags to apply. It really depends on whether
you're trying to track this at a story or task level (there is no
per-task tagging implemented yet at any rate). I could imagine, for
example, setting something like tripleo-r2 as a tag on stories whose
TripleO deliverable tasks are targeting Rocky milestone #2, and then
you could have an automatic board with stories matching that tag and
lanes based on the story status.
> - how to update old Launchpad bugs with the new link in storyboard
> (probably by hacking the migration script during the import).
We've debated this... unfortunately mass bug updates are a challenge
with LP due to the slowness and instability of its API. We might be
able to get away with leaving a comment on each open LP bug for a
project with a link to its corresponding story, but it would take a
long time and may need many retries for some bugs with large numbers
of subscribers. Switching the status of all the LP bugtasks en masse
is almost guaranteed to be a dead end since bugtask status changes
trigger API timeouts far more often based on our prior experience
with LP integration, though I suppose we could just live with the
idea that some of them might be uncloseable and ignore that
fraction. If the migration script is to do any of this, it will also
need to be extended to support LP authentication (since it currently
only performs anonymous queries it doesn't need to authenticate).
Further, that tool is currently designed to support being rerun
against the same set of projects for iterative imports in the case
of failure or to pick up newer comments/bugs so would need to know
to filter out its own comments for purposes of sanity.
> - how do we want the import to be like:
> * all bugs into a single project?
Remember that the model for StoryBoard is like LP in that stories
(analogous to bugs in LP) are themselves projectless. It's their
tasks (similar to bugtasks in LP) which map to specific projects and
a story can have tasks related to multiple projects. In our
deployment of SB we create an SB project for each Git repository so
over time you would expect the distribution of tasks to cover many
"projects" (repositories) maintained by your team. The piece you may
be missing here is that you can also define SB projects as belonging
to one or more project groups, and in most cases by convention
we've defined groups corresponding to official project teams (the
governance concept of a "project") for ease of management.
> * closing launchpad/tripleo/bugs access? if so we loose web search
> on popular bugs
They don't disappear from bugs.launchpad.net, and in fact you can't
really even prevent people from updating those bugs or adding
bugtasks for your project to other bug reports. What you have
control over is disabling the ability to file new bugs and list
existing bugs from your project page in LP. I would also recommend
updating the project description on LP to prominently feature the
URL to a closely corresponding project or group in SB.
Separately, I notice https://storyboard.openstack.org/robots.txt has
been disallowing indexing by search engines... I think this is
probably an oversight we should correct ASAP and I've just now added
it to the agenda to discuss at today's Infra team meeting.
> - (more a todo) update the elastic-recheck bugs
This should hopefully be more of a (trivial?) feature add to ER,
since the imported stories keep the same story numbers as the bugs
from which they originated.
> - investigate our TripleO Alerts (probably will have to use Storyboard
> API instead of Launchpad).
Thankfully, SB was designed from the very beginning in an API-first
manner with the WebUI merely one possible API client (there are also
other clients like the boartty console client and a . In theory
pretty much anything you can do through the WebUI can also be done
through the API, as opposed to LP where the API is sort of
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 963 bytes
Desc: not available
More information about the OpenStack-dev