Open Stack

Thanks for starting this thread Ian.

On Tue, Jun 11, 2019 at 4:09 AM Ian Wienand <iwienand at redhat.com> wrote:
> It seems ARA 1.0 has moved in some directions we're not handling right
> now.  Playing with [1] I've got ARA generating and uploading it's
> database.

Patch looks good to me.
Thanks for playing with it :)

> Currently, Apache matches an ara-report/ directory on
> logs.openstack.org and sent to the ARA wsgi application which serves
> the response from the sqlite db in that directory [2].

Correct.

> If I'm understanding, we now need ara-web [3] to display the report
> page we all enjoy.  However this web app currently only gets data from
> an ARA server instance that provides a REST interface with the info?

Correct.

> I'm not really seeing how this fits with the current middleware
> deployment? (unfortunately [4] or an analogue in the new release seems
> to have disappeared).  Do we now host a separate ARA server on
> logs.openstack.org on some known port that knows how to turn
> /*/ara-report/ URL requests into access of the .sqlite db on disk and
> thus provide the REST interface?

The sqlite middleware doesn't have an equivalent in 1.0 right now.

Although it was first implemented as somewhat of a hack to address the
lack of scalability of HTML generation, I've gotten to like the design
principle of isolating a job's result in a single database.

It easy to scale and keeps latency to a minimum compared to a central
database server.

I'm convinced that implementing a similar approach for 1.0 would make
sense. I would happily accept any input here.

> And then somehow we host a ara-web instance that knows how to
> request from this ?

Right now the API server is defined by the configuration [1].
We would need to implement a more "dynamic" way of being able to
specify an API endpoint to query.

For example, we recently added support for ara-web to prompt a login
page if the API server requires authentication. The credentials are stored
locally and then used to authenticate queries against the API.

It might not be too much of a stretch to implement a way to store the
API endpoint locally like we do for credentials.

We wouldn't want the user(s) to type in the API endpoint every time, though.
There is a little thinking to do about how to glue the things together.

The combination of the rewrite rule, the wsgi middleware and the fact that
0.x was a monolithic app definitely made this easier.

> Given I can't see us wanting to do a bunch of puppet hacking to get
> new services on logs.openstack.org, but yet also it requiring fairly
> non-trivial effort to get the extant bits and pieces on that server
> migrated to an all-Ansible environment, I think we have to give some
> thought as to how we'll roll this out (plus add in containers,
> possible logs on swift, etc ... for extra complexity :)
>
> So does anyone have thoughts on a high-level view of how this might
> hang together?

For now I've created an etherpad [2] as a starting point to summarize
some of what has been written here as well as other points which are perhaps
more Zuul-specific.

[1]: https://github.com/ansible-community/ara-web/blob/master/public/config.json
[2]: https://etherpad.openstack.org/p/ara-1.0-in-zuul

David Moreau Simard
dmsimard = [irc, github, twitter]