Thanks for starting this thread Ian. On Tue, Jun 11, 2019 at 4:09 AM Ian Wienand <iwien...@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] _______________________________________________ OpenStack-Infra mailing list OpenStack-Infra@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
