Yay, the web side catching up!
On 27 July 2017 at 03:50, Monty Taylor wrote:
> Based on having written the puppet to support the apache proxying to both
> github/status pages and the console-streaming, I believe we should
> accelerate moving the functions from the old webapp to the new zuul-web.
>
> While the apache proxy layer keeps the moves from breaking our end-users,
> doing the moves will break anyone doing deployments of zuul CD from git
> unless we tightly coordinate with them. As that's the way we prefer to run
> normally in Infra, it's reasonable to expect other people to desire running
> that way as well. While we can, in Infra, be careful when we land changes
> and then update the puppet url mapping before we restart the services, once
> there is another deployer it's hard to coordinate. So the web functions in
> the scheduler should be moved to zuul-web at the very least before we cut
> v3. I'd prefer to just go ahead and move them before Denver, because I'd
> rather not do the puppet dance after we go live.
>
> I've written a first pass at doing this that doesn't move anything but
> that replaces webob with aiohttp. I did this when jlk was having issues
> with unicode in the github webhook out of curiosity and it wasn't that bad.
> I'll push that up in just a sec. Before we get to patches though, I keep
> saying I'm going to write up thoughts on how this wants to look in the end
> - so here they are:
>
> The shape of what things want to look like
> --
>
> zuul-web wants to serve all http and websocket content. It's a stateless
> app, so it can be simply scaled-out and load-balanced as desired.
>
> At the moment the http content is split between zuul-web and webapp and
> the urls need to be rewritten/proxied to be contiguous.
>
> static assets want to be in a '/static' path and served by zuul-web - but
> all prefixed with '/static' so that it's easy for installations to serve
> static content directly with apache. The path "static" can certainly be
> debated - but it's working for now. The main point is that we want a
> portion of the URL space to be easily servable by a static web server for
> large installs, but also easily servable directly by zuul-web for small
> ones.
>
Not to bikeshed here, but also about being able to push static to a CDN, so
yea, just don't bake anything in.
>
> It needs to be possible to run zuul-web on a sub-url, such as
> https://ci.example.com/zuul - We should endeavor to properly detect this
> from the appropriate http headers which we are not doing right now, but we
> should continue to provide a config setting so that admin can set it if for
> some reason we can't detect it properly from headers.
>
> REST endpoints fall in to two categories - global and per-tenant. Most
> urls should be per-tenant, but some, like the github webhook listener, need
> to be global.
>
> The url scheme served by zuul-web should be:
>
> /connection/{connection}
> /tenant/{tenant}
>
> so -
>
> /connection/github/payload
> /tenant/openstack/status
>
> ** Question - should we shift them all down a tick to be under /api or
> similar?
>
> The tenant namespace has the follwing endpoints:
>
> /tenant/{tenant}/console-stream
> /tenant/{tenant}/status
> /tenant/{tenant/{status}/change/{change}
> /tenant/{tenant}/keys/{source}{project}.pub
>
> It needs to be possible to expose the websocket stream on a different url,
> such as zuul-web being on https://ci.example.com/zuul and websocket being
> on https://internal.example.com/zuul/console-stream.
>
> We need to be able to allow an admin to configure an override for the
> websocket location (this is already done)
>
> Server-side rendering of html should be avoided, preferring instead
> serving html, css, images and javascript files from /static and having
> those fetch information from api endpoints on zuul-web. (more on this later)
>
> For now the html/javascript web-content is in the zuul repo. Depending on
> how we wind up feeling about javascript tooling we may want to discuss
> splitting it into its own repo - but it's not actually necessary to do so.
> (again, more on javascript tooling later)
> Actually moving things from scheduler to zuul-web
>
-
>
> - make both a register-per-tenant and a register-global function for
> registering handlers
>
> Most places want to register per-tenant and only per-tenant. but the
> github webhook wants to be global, so we at least need the ability. It's
> also POSSIBLE an admin might want to make an admin status console. We
> should not implement that until we have an actual need for it - but having
> the ability at registration time is important.
>
> - moving status to zuul-web
>
> We will need a gearman function on the scheduler for getting the status
> info. We can just ship the entire status info from the scheduler to
> zuul-web and do caching/filtering there. Should be fairly trivial.
>
> -
