Open Stack

On 6 September 2017 at 01:26, James E. Blair <corvus at inaugust.com> wrote:

> Darragh Bailey <daragh.bailey at gmail.com> writes:
>
> > Hi,
> >
> > Currently the main issue from end users, is the user experience around
> the
> > UI when looking at job results once the run is complete, and to a lesser
> > extend looking at your jobs in the zuul status page when running.
> >
> > I'm wondering if there is a plan to have a full UI covering both
> historical
> > job runs for projects as well as live status reporting?
>
> Yes, Tristan has started work on that, and we plan to continue it after
> we migrate openstack to Zuul v3.
>

Is there a link to where this is being tracked/discussed?


> > I've noticed there is an SQL reporter, should that be leveraged to
> provide
> > access to the sort of information that needs to be tracked? Or should
> > something else be used such as simple files to identify success/failure?
>
> Yes, we plan on using it to supply the historical data.
>
> > 1) Project status view:
> >
> > The main status page can be useful for those supporting zuul in an
> > environment to have a quick overview of everything, however feedback
> we've
> > received locally suggests most developers are frequently only interested
> in
> > a single project and find this to be overwhelming This suggests there
> > should be a per-project status view, showing only the pipelines and
> changes
> > of interest for a single project, along with any CRD that are linked.
> >
> > Possibly under an endpoint of "/<project>/" as the default view showing
> any
> > pipelines relevant to the project along with any changes going through
> them.
>
> That sounds reasonable once we have the new web framework in place.
>

Are there stories on this area? Presumably the endpoint being queried would
provide similar information so it might be possible for someone to work on
this in parallel and then adjust without too much difficultly to use more
appropriate API queries, or when you refer to a web framework do mean the
client side web components?


> > 2) Project build history view:
> >
> > Returning links at the end of a run in a comment to the raw log files as
> > the only build history is somewhat jarring for people used to the
> > Travis/Drone/Circle CI services available, there's the expectation that
> it
> > should be easily to see the previous runs, seeing whether they passed,
> > which jobs within a set failed, and to display the detailed log when
> > desired. Providing a reasonable UI is becoming a pre-requisite for
> > adoption, no matter how good the functionality, it can be difficult to
> get
> > acceptance if the "form" is deemed limiting (non all follow this, but it
> > does seem that some of the most vocal objectors can fall into this area).
>
> I'm a little confused by this one.  I agree they should be available,
> but I think they already are.  Zuul currently provides (in a comment, as
> you say) the overall pass/fail status of the build set, the pass/fail
> status of individual jobs, that same information for previous runs on
> the change, and links to the detailed logs.  In Github, the presentation
> of that available to us is somewhat limited, but I think in Zuul v3
> we're approaching a reasonable compromise.  Note this may be
> significantly different that what you are running.
>

I believe it provides this back to the corresponding PRs, but it would be
nice if from the zuul interface if I'm looking at a failed job, that 'a' it
doesn't suddenly disappear once all the other jobs in the set are complete,
and 'b' it's possible to quickly look to another recent run that was
executed due to another change within the same project.

I haven't been running the zuulv3 code base yet, maybe you already have
some of these improvements in place, and I'll see them as I start
experimenting with it.


> If you're suggesting that there should *also* be a way to find that
> information from a main Zuul web page, yes, I think that would be
> covered by the previous point.
>

Yes, I meant that if you are looking at your change and the job failed,
finding/seeing previous runs of the same job for the same project is
currently difficult, but if they could easily switch to seeing them, and
also seeing others that passed since their change was tested it helps focus
on the problem being due to the change at hand.



> I would like to point out though that Zuul's primary user interface
> always has been, and will continue to be, the code review system.
> That's on purpose.  The recognition that a developer should have all the
> information about a change, including test results, at their fingertips
> is one of the earliest innovations in Zuul; only now are facilities
> appearing in Github *and* Gerrit to support this the way we've always
> wanted.  The web interface will be a complement, not a replacement, for
> this.  That doesn't mean the on-change reporting is frozen, we will
> happily continue to improve the UX there (especially with the new tools
> available to us).
>
> > 3) Change view
> >
> > Users of tools such as GitHub are expecting a link to appear on the PR
> > status checks that can then be followed to see the state of the job(s)
> > currently executing. Currently this can be enabled through setting of a
> > config option "status_url_with_change" in the zuul section. This can also
> > be used with Gerrit making it easy to quickly see a single change.
>
> That config option does not appear in my tree.  However, I believe the
> Github support in Zuul v3 already supports what you describe.
>

Yes, it came in from the BonnyCI fork of github.


> > Are these of any interest?
> >
> > I'm no UI expert, so I'm just identifying some of the pieces that we hear
> > feedback over and hoping that if I can help get the necessary information
> > exposed and appearing at the right places someone else might know how to
> > make it look nice..
>
> Thanks for the use cases.  I think what you're looking for is not
> radically different than the rest of the team.  It may be helpful for
> you to start testing Zuul v3, as I think some of the areas you're
> finding rough edges are different there.  Once you do so, I'm sure I and
> others will be happy to help work out any remaining issues.
>
> Expect effort on the historical web interface and rest API to begin
> after OpenStack migrates to Zuul v3.  It'd be great if you can pitch in
> on that with either reviews or code once we get going.  None of us
> describe ourselves as javascript developers, so we aim to keep that area
> pretty accessible.
>
> -Jim
>

Just getting back looking at this again, but as it's of interest to users
locally, it should be possible to get time to work on them, and we
certainly don't want to hack something onto a local copy.

If there are any stories in this area I'd love to try and track them and
start chatting with those looking in this area as is

-- 
Darragh Bailey
"Nothing is foolproof to a sufficiently talented fool"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20170919/5d091bc2/attachment.html>