Open Stack

On Tue, Jan 16, 2018 at 8:29 AM, Jeremy Stanley <fungi at yuggoth.org> wrote:
> 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.

well - I wanted root access to hack myself. If I need the -dev
instance I'll ask ok.

>
>> - 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.

Does this kind of board exist already?
Something like https://launchpad.net/tripleo/+milestone/queens-3 maybe.
If the answer is "no but we can do it", fine but keep in mind this is
a blocker for us now.

I created a story: https://storyboard.openstack.org/#!/story/2001479

>> - 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.

I'm fine to not update closed bugs but we should update ongoing bugs
before closing them.
We don't want let our users in a situation where their bugs closed and
they don't know what to do.
Not everyone is reading this mailing-list and having a nice message
posted on Launchpad will be a requirement.

I created a story: https://storyboard.openstack.org/#!/story/2001480

>> - 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.

ack

>>   * 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.

ack

> 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.

It would be great.

>> - (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.

Yeah, trivial but worth noting (more for our todo).

>> - 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
> bolted-on.

I'm not concerned about that one, the API will indeed help us here.

Thanks Jeremy for your help,
-- 
Emilien Macchi