1096531 - figure out how to integrate new balrog ui with existing balrog repo

Status: RESOLVED FIXED

(Release Engineering Graveyard :: Applications: Balrog (frontend), defect)

Description

[[e-mail] (:bhearsum)]

Currently, the new Balrog UI lives in https://github.com/mozilla/balrog-ui, which is a completely separate repo than Balrog. This isn't necessarily bad, because it can be run 100% standalone, but we need to figure out how this is going to work with how we deploy. I'm particularly concerned about cases where we have a backend and frontend change that need to land together (for example, some sort of backwards incompatible API change).

This will be easier once bug 1096528 is done, and I'd like to chat with IT to make sure we don't make plans to deploy in a way that doesn't work for them.

Comment 1

[[e-mail] (:bhearsum)]

I started looking at this and so far I've come up with https://github.com/bhearsum/balrog/compare/bhearsum:balrog-ui-backend...balrog-ui-integration?expand=1 (note: this is built on top of bug 1096528).

The main highlight here is that it's a full import of the balrog-ui repository. I _think_ this will work best with how we deploy. I don't think keeping balrog and balrog-ui completely separate would work because it would be impossible to deploy changes simultaneously. Keeping balrog-ui as a submodule in balrog might be possible, and I want to talk to IT about if that might work.

Other highlights include:
* Land a production-built version of the ui in ui/dist. This means that the development process probably looks like this:
-- hack hack hack, commit
-- get r+
-- build ui with "lineman build"
-- commit and merge to master
* Update vagrant environment to serve ui. This is a bit of hack because Angular doesn't like to be served anywhere other than /, and we can't move the wsgi app out of / because the submitter tools depend on it being there. I've worked around this by hosting the angular app in /ui and rewriting its real endpoints to /ui/*. I want to talk to webops about this to see if they have a better way, as we'll need to do something similar in production.

Comment 2

[[e-mail] (:bhearsum)]

Attachment: apache config to support new ui

I spoke with cturra about how this would work for IT today. First of all, he said that using a submodule for the ui would be fine - so let's do that, it seems much nicer than merging the repositories given that the UI is fully independent from a development standpoint.

Secondly, we talked about deployment of the new UI. Chris, here's the Apache config from our Vagrant environment with the rewrite hacks that I mentioned. You'll see that the wsgi app continues to be hosted at / (just like prod), which is because we have tools and scripts that depend on many of those endpoints. The UI is hosted at /ui via the Alias, but all of the endpoints it loads (eg, /js/app.js) need to be rewritten, because the Angular app is unable to look at /ui for them. I fiddled around with other ways to do this using various RewriteCond and Options, but this is the only thing that I found worked. If you can come up with anything better, great =).

In the long term, I think the better solution is to move the API to its own domain (aus4-api, maybe?), but we'll need a period where they're both available in order to make that work.

Comment 3

[[e-mail] (:bhearsum)]

(In reply to Ben Hearsum [:bhearsum] from comment #2)
> Created attachment 8524622 [details]
> apache config to support new ui
> 
> I spoke with cturra about how this would work for IT today. First of all, he
> said that using a submodule for the ui would be fine - so let's do that, it
> seems much nicer than merging the repositories given that the UI is fully
> independent from a development standpoint.
> 
> Secondly, we talked about deployment of the new UI. Chris, here's the Apache
> config from our Vagrant environment with the rewrite hacks that I mentioned.
> You'll see that the wsgi app continues to be hosted at / (just like prod),
> which is because we have tools and scripts that depend on many of those
> endpoints. The UI is hosted at /ui via the Alias, but all of the endpoints
> it loads (eg, /js/app.js) need to be rewritten, because the Angular app is
> unable to look at /ui for them. I fiddled around with other ways to do this
> using various RewriteCond and Options, but this is the only thing that I
> found worked. If you can come up with anything better, great =).
> 
> In the long term, I think the better solution is to move the API to its own
> domain (aus4-api, maybe?), but we'll need a period where they're both
> available in order to make that work.

flagging to get your attention

Comment 4

[[e-mail] (:bhearsum)]

Attachment: add production files to ui repo

Comment 5

[Peter Bengtsson [:peterbe]]

Comment on attachment 8524831 [details] [review]
add production files to ui repo

merged

Comment 6

[[e-mail] (:bhearsum)]

Attachment: Integrate UI repository with main repo

The first and last hunk are the submodule parts. You can test this out by cloning my Balrog repo, switching to the ui-submodule branch, and then running "git submodule update --init". After that, the repos operate more or less independently, except that balrog will be marked as modified whenever the ref in the ui repo changes.

Comment 7

[Nick Thomas [:nthomas] (UTC+12)]

Comment on attachment 8525343 [details] [diff] [review]
Integrate UI repository with main repo

Mostly a stampy r+, feel free to find someone with more webdev for more thorough check. One question, what does a 50 request limit mean for doing dev on either the backend or UI ? Lots of shift-refreshing or httpd restarts ? I know it will make the responses massively more fun to wait on.

Comment 8

[[e-mail] (:bhearsum)]

(In reply to Nick Thomas [:nthomas] from comment #7)
> Comment on attachment 8525343 [details] [diff] [review]
> Integrate UI repository with main repo
> 
> Mostly a stampy r+, feel free to find someone with more webdev for more
> thorough check. One question, what does a 50 request limit mean for doing
> dev on either the backend or UI ? Lots of shift-refreshing or httpd restarts
> ? I know it will make the responses massively more fun to wait on.

It does mean shift refreshes may be necessary after making code changes. I made this change because I noticed that the wsgi process would reload multiple times in one page load (because multiple requests are made to it for one page load), which slowed things down quite a bit. We can tweak this to something else - it was just a value I pulled out of thin air.

Comment 9

[[github robot]]

Commit pushed to master at https://github.com/mozilla/balrog

https://github.com/mozilla/balrog/commit/6bd5a6accf83b3b23a01f55ad7e474473c61970d
bug 1096531: figure out how to integrate new balrog ui with existing balrog repo - add ui repo as a submodule. r=nthomas

Comment 10

[[e-mail] (:bhearsum)]

Comment on attachment 8525343 [details] [diff] [review]
Integrate UI repository with main repo

I went ahead and pushed this. We can fiddle with the web bits later if someone (eg, IT) comes up with something better for the ProxyPass bits. The version in this repo is just for local development anyways, and this version works well enough for now.

Comment 11

[[e-mail] (:bhearsum)]

With the code changes all having landed, I've filed bug 1102212 to ask IT to enable the new UI, starting with aus4-admin-dev.

Comment 12

[[e-mail] (:bhearsum)]

Dev looked good, we've got bug 1104163 for prod now. After that, I'm going to call this fixed.

Comment 13

[[e-mail] (:bhearsum)]

All done here \o/. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1104718 to remove the rewrite hacks from our initial deployment, and https://bugzilla.mozilla.org/show_bug.cgi?id=1104719 to track killing the old ui.