505803 - Web app to allow new machines / branches to be added to graph server

Status: RESOLVED FIXED

(Webtools Graveyard :: Graph Server, defect, P1)

Description

[Chris AtLee [:catlee]]

It would be great for releng to have a web application that allowed us to add new machines or branches to the graph server.

Comment 1

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Should this be a GraphServer bug?

Comment 2

[Chris Cooper [:coop] (he/him)]

Mass move of bugs from Release Engineering:Future -> Release Engineering. See
http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.

Comment 3

[Lukas Blakk [:lsblakk] use ?needinfo]

I don't see having time for this in the near future, maybe someone else will.

Comment 4

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

This is about changes to GraphServer, so pushing over to WebDev. 

Currently, we have to post SQL patches for IT to land in graphserver before a new machine or new branch can be enabled. It would be much better if RelEng could use some UI to self-serve instead.

Comment 5

[Dave Miller [:justdave]]

lsblakk is actually working on this right now (I just saw a mockup of it in email), so assigning.  The bug mentioned in the email wasn't this one. (maybe it's a dupe now?)

Comment 6

[Dave Miller [:justdave]]

The bug mentioned in the email was bug 627499.

Comment 7

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: graphserver.php form & database entry

Here's another stab at the form to enter our new branches into graphserver - can we get something like this set up behind LDAP on stage & production?

Comment 8

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: graphserver.php form & database entry [typo fixed on checkbox]

Comment 9

[Dave Miller [:justdave]]

Comment on attachment 513829 [details]
graphserver.php form & database entry [typo fixed on checkbox]

Looks good to me.  The attachment looks like partial HTML to me, does php run it just like this?  Easiest place to put it is probably on the graph server with apache configured to only allow access to it from internal IP addresses (which will effectively put it behind VPN).

Comment 10

[Lukas Blakk [:lsblakk] use ?needinfo]

> The attachment looks like partial HTML to me, does php run
> it just like this?  

I'll test it with a local mysql db and make sure, it should work.

Comment 11

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: input.php for running on {staging,production} graphserver

This version has been tested on my local 'graphs' db which I set up using the schema.sql for our graphs db.  It works all as one file, with a config.php which contains:
<?php
  // Database settings
  $dbuser = 'root';
  $dbpass = 'password';
  $dbhost = 'localhost';
  $dbname = 'graphs';
?>

Could we try setting this up on stage graphserver and doing a test run to make sure that it's secure and does insert to stage graphserver?

Comment 12

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: the correct input.php file

the last one was the old version. This is the new one.

Comment 13

[Lukas Blakk [:lsblakk] use ?needinfo]

Also - what do you think about extending this page to also show what's in the branches and machines tables and possibly allowing delete?

Comment 14

[Laura Thomson :laura]

Moving over to graph server product and reassigning as per discussion with catlee.

Comment 15

[Robert Helmer [:rhelmer]]

I will test this and get landed on the 1.0 branch, we should definitely keep it LDAP-only.

For the 2.0 version I think we could easily do this in Python and have it live with the rest of the backend code.

The only concern I have is that the current system (checking into a .sql file and having IT push it) leaves a better paper trail, for setting up new systems or tracking down mistakes.

I think it's not really a big deal, as long as we're making regular backups of the production DB.

Comment 16

[alice nodelman [:alice] [:anode]]

I do think that it is useful to have the data.sql file for quickly setting up home/staging graph servers - but we might be able to reproduce that functionality by providing a dump of specific tables in the db on a periodic basis.

We are losing the double check that a patch provides, though.  Fixes to machine/test names and other info has been made during patch review for data.sql.  By allowing immediate application to the db we could end up giving ourselves more work down the line fixing up mistakes.

Comment 17

[Chris AtLee [:catlee]]

(In reply to comment #15)
> I will test this and get landed on the 1.0 branch, we should definitely keep it
> LDAP-only.
> 
> For the 2.0 version I think we could easily do this in Python and have it live
> with the rest of the backend code.
> 
> The only concern I have is that the current system (checking into a .sql file
> and having IT push it) leaves a better paper trail, for setting up new systems
> or tracking down mistakes.

We've never had IT push the sql file. We've had them just apply the individual changes.

> I think it's not really a big deal, as long as we're making regular backups of
> the production DB.

agreed

Comment 18

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 514241 [details]
the correct input.php file

Rhelmer - is it possible to get this or some kind of CRUD access to the {staging,production} graphservers up behind LDAP soon?  Adding new project branches is happening more frequently and this is the only place where RelEng can't make the changes by themselves. The input.php file I've attached is an example of how simple this needs to be - but I trust you know better than I how to let us be able to add/update entries in the graphserver branch & machine tables without having the powers to destroy it all.

Comment 19

[Robert Helmer [:rhelmer]]

Attachment: create python CGI for adding branches

This is pretty much a direct translation of attachment 513241 [details]. I am still doing some testing on it and may make some changes to make it more pythonic and add more error checking, let me know if anything jumps out at you.

Comment 20

[Chris AtLee [:catlee]]

Comment on attachment 534026 [details] [diff] [review]
create python CGI for adding branches

Looks basically ok...

I think you need to be printing "HTTP/1.0 200 OK" instead of "Status: 200" as the first line of the response.

I don't like hardcoding the platform_id in the html file. I don't think this is well defined or guaranteed to not change. Better to look up the id in addBranch for the given machine name.

Comment 21

[Robert Helmer [:rhelmer]]

(In reply to comment #20)
> Comment on attachment 534026 [details] [diff] [review] [review]
> create python CGI for adding branches
> 
> Looks basically ok...
> 
> I think you need to be printing "HTTP/1.0 200 OK" instead of "Status: 200"
> as the first line of the response.

Hmm yeah I based this CGI on one of the existing ones, some things in it like this don't make sense to me but I left it for the sake of consistency. I'll just go through and change it to make sense; some of these things should probably be refactored to something common (sendJsonResponse(), for example)
 
> I don't like hardcoding the platform_id in the html file. I don't think this
> is well defined or guaranteed to not change. Better to look up the id in
> addBranch for the given machine name.

ok, will do. Thanks!

Comment 22

[Lukas Blakk [:lsblakk] use ?needinfo]

how is this coming along?  it's a blocker on one of my quarterly goals so if by the end of next week there was something usable up for inserting new branches to staging and production that would be very awesome.  if that's not possible, an idea of when to look forward to having this would be great too. cheers.

Comment 23

[Robert Helmer [:rhelmer]]

(In reply to comment #22)
> how is this coming along?  it's a blocker on one of my quarterly goals so if
> by the end of next week there was something usable up for inserting new
> branches to staging and production that would be very awesome.  if that's
> not possible, an idea of when to look forward to having this would be great
> too. cheers.

I may go on paternity leave any moment so I am trying to tie things up :)
I will endeavor to do this by end of next week, there's not much left to do at this point.

Comment 24

[Lukas Blakk [:lsblakk] use ?needinfo]

Bring this back to life again - how close are we to having this up in staging/production?  Is anything blocking this that I can help with?

Comment 25

[Chris Cooper [:coop] (he/him)]

(In reply to Lukas Blakk [:lsblakk] from comment #24)
> Bring this back to life again - how close are we to having this up in
> staging/production?  Is anything blocking this that I can help with?

To echo Lukas, this is pretty important for us. Waiting on graphserver additions is a big speedbump for releng in the current process for deploying new hardware.

Comment 26

[Robert Helmer [:rhelmer]]

(In reply to Chris Cooper [:coop] from comment #25)
> (In reply to Lukas Blakk [:lsblakk] from comment #24)
> > Bring this back to life again - how close are we to having this up in
> > staging/production?  Is anything blocking this that I can help with?
> 
> To echo Lukas, this is pretty important for us. Waiting on graphserver
> additions is a big speedbump for releng in the current process for deploying
> new hardware.

Sorry for the delay, keep getting preempted.

The patch works as-is, I just haven't had time to address catlee's points in comment 20. I think the "Status:" thing is actually fine, but doing a looking in the DB to get the platform_id instead of hardcoding in the input.html is a good idea.

If anyone else has time to finish these up feel free, I'll try to get to it this week though.

Comment 27

[Lukas Blakk [:lsblakk] use ?needinfo]

> 
> If anyone else has time to finish these up feel free, I'll try to get to it
> this week though.

I've actually started writing a flask webapp to work with the db that would give us CRUD access through an API, what I have right now is here: https://github.com/lsblakk/graphserver-webapp and I should have something more final in the next week or so.  When it's ready I can hand it over so it can be implemented with the correct auth configs.

Comment 28

[Robert Helmer [:rhelmer]]

(In reply to Lukas Blakk [:lsblakk] from comment #27)
> > 
> > If anyone else has time to finish these up feel free, I'll try to get to it
> > this week though.
> 
> I've actually started writing a flask webapp to work with the db that would
> give us CRUD access through an API, what I have right now is here:
> https://github.com/lsblakk/graphserver-webapp and I should have something
> more final in the next week or so.  When it's ready I can hand it over so it
> can be implemented with the correct auth configs.

Having this be a separate, internal-only app actually sounds like a great idea.

I'd like to avoid building more on top of the olde-world CGI graphserver backend if possible.

Comment 29

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: graphserver-webapp flask app for add/remove branches/machines

available on github if you prefer: https://github.com/lsblakk/graphserver-webapp

Comment 30

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: graphserver-webapp flask app for add/remove branches/machines

Incorporated feedback from Catlee about the earlier patch:
1. Split out the 'GET', 'POST', and 'DELETE' into their own methods
2. created an is_json function
3. removed duplicated tests and simplified
4. took out using session for version and just passing it to the template now

Code is also up to date at https://github.com/lsblakk/graphserver-webapp if that's easier to look at.

Comment 31

[Lukas Blakk [:lsblakk] use ?needinfo]

Attachment: (final) webapp now with logging

Comment 32

[Lukas Blakk [:lsblakk] use ?needinfo]

Rhelmer: I've landed this in our tools repo: http://hg.mozilla.org/build/tools/file/ca6578f7a4a2/graphserver_webapp

Can you help me get this set up on staging to run a test on the live staging db with the proper configs?  Ideally this would run in a virtualenv as it needs Flask installed (http://flask.pocoo.org/docs/).

Comment 33

[Robert Helmer [:rhelmer]]

(In reply to Lukas Blakk [:lsblakk] from comment #32)
> Rhelmer: I've landed this in our tools repo:
> http://hg.mozilla.org/build/tools/file/ca6578f7a4a2/graphserver_webapp
> 
> Can you help me get this set up on staging to run a test on the live staging
> db with the proper configs?  Ideally this would run in a virtualenv as it
> needs Flask installed (http://flask.pocoo.org/docs/).

Sure, ping me tomorrow and we can get it set up at least enough to test (may have to do a little more work to make IT happy to install it in prod).

Comment 34

[Dave Miller [:justdave]]

Any progress?  Saw another one of these go through IT's queue earlier today, would love to have this. ;)

Comment 35

[Robert Helmer [:rhelmer]]

(In reply to Dave Miller [:justdave] from comment #34)
> Any progress?  Saw another one of these go through IT's queue earlier today,
> would love to have this. ;)

Yep, working on installing this on stage now!

Comment 36

[Lukas Blakk [:lsblakk] use ?needinfo]

I've removed the /delete and replaced with /update for both webapp and API - ready to go again with implementing this at least on staging for testing?

Up-to-date code is here: https://github.com/lsblakk/graphserver-webapp

Comment 37

[Lukas Blakk [:lsblakk] use ?needinfo]

Poking this on staging, looks good.  Can we get this enabled in production now?

Comment 38

[Lukas Blakk [:lsblakk] use ?needinfo]

also - the code is here: http://hg.mozilla.org/build/tools/file/tip/graphserver_webapp

Comment 39

[Robert Helmer [:rhelmer]]

(In reply to Lukas Blakk [:lsblakk] from comment #37)
> Poking this on staging, looks good.  Can we get this enabled in production
> now?

We had to very quickly create a new prod/stage environment in the new datacenter, since the old one is being decommissioned tomorrow (see bug 750962)

So we'll need to get this set up again. We'll need to get the install documented in https://mana.mozilla.org/wiki/display/websites/graphs.mozilla.org anyway (so this is a good chance to do so :) )

Comment 40

[Robert Helmer [:rhelmer]]

(In reply to Robert Helmer [:rhelmer] from comment #39)
> https://mana.mozilla.org/wiki/display/websites/graphs.mozilla.org 

Now working on stage, documented in mana URL above, and filed bug 753567 to get this into production (and further puppetized while we are at it).

Comment 41

[Lukas Blakk [:lsblakk] use ?needinfo]

Production webapp: http://graphs1.dmz.scl3.mozilla.com:8080/
Staging webapp: http://graphs1.stage.dmz.scl3.mozilla.com:8080/

Code for webapp: http://hg.mozilla.org/build/tools/file/tip/graphserver_webapp/webapp
Mana page for IT deployment info: https://mana.mozilla.org/wiki/display/websites/graphs.mozilla.org#graphsmozillaorg-Developmentdocumentation