A new badges01 VM for the badges consumer is a good idea.

The webapp should likely have its own VM as well. The app is built on pyramid which may or may not have some ugly conflicts with our TG2 stack (like python-webob1.2). We might be able to fit it all on app0*, but things will likely be easier if we separate them out (assuming we have the resources to spin up new VMs).

Can someone comment on the best way forward for creating the database and tables? I haven't had a hand in that, yet.

I wrote an "RFC" about creating databases a long time ago but I don't think any of the app developers follow it even though they thought it was sensible. :-)

• We'll use a database superuser to create a db and thus own it
• The db superuser will create the schema for the db
• The db supervisor will grant the necessary permissions to select, insert, and update to a db user $DBNAMEapp which will be used for the web application's day-to-day operation. The password for this must necessarily be added to a config file where the web app runs
• Additional db accounts can be created that target the specific permissions that are needed by pieces of the system (for instance, if a cron job needs to add to tables that the web app would never write to)
• Schema updates should not be possible by the $DBNAMEapp account

I agree with/support toshio's database guidelines. ;)
In addition, personally, I would say I prefer postgresql over mysql.

Perhaps we should have this discussion on the mailing list? To allow for more widespread discussion?

Anyhow, from reading the design doc and such, I think it probibly would make sense to have two instances:

badges-backend01 and badges-web01 ? Or... if we are going to be moving more apps to pyramid, would it make sense to make the frontend 'pyramid-app01' and then use it for more things as we have them?

I guess caching/varnish wouldn't make much sense for the web app really? (it's only going to get hit when people look up their badges or add them to their backpack? or does it get called anytime someone wants to say list all their badges on a page?)

Oh, one additional note: Typically for new services like this we go through a RFR (Request for Resources) process.
See: http://fedoraproject.org/wiki/Request_For_Resources and https://fedoraproject.org/wiki/Request_for_resources_SOP

Might look through those for any process help... :)

Replying to [comment:4 kevin]:

Oh, one additional note: Typically for new services like this we go through a RFR (Request for Resources) process.
See: http://fedoraproject.org/wiki/Request_For_Resources and https://fedoraproject.org/wiki/Request_for_resources_SOP

Might look through those for any process help... :)
Thanks! I will look through all of that today.

I just rediscovered this ticket and am assigning it to myself. :)

Reviving this ticket yet again.

I'm changing the properties to reflect a request for resources for a badges-web01.stg for the pyramid WSGI app and badges-backend01 for the fedmsg consumer. oddshocks is finishing up his school semester now and starts his internship on May 28th. We'll likely spend a couple weeks iterating on a cloud dev instance before pushing anything to staging, so this isn't all that urgent.

Creating a badges-web01.stg host follows in the pattern we're trying to establish of having different web services on different nodes, for debug/isolation purposes.

Creating a badges-backend01.stg host tries to mimic that pattern. Right now busgateway01 functions kind of like our app servers. It is a catch-all where every fedmsg-consuming thing we have is running. If we're intending to separate our app servers out to be service-specific, we should probably follow the same pattern for fedmsg consumers. If we keep them all on the same box and it starts to flip out, how do we determine which fedmsg consumer is to blame?

+1 on isolating services. Let me know if there is anything I can do to help move this forward. Today indeed marked the final day of non-Red-Hat work for me.

Ping here. I'm looking at the calendar, and the final freeze for F19 starts a week from today. Our goal is to get the badges stack up, working, and have the first badges awarded at Flock in early August.
We might be able to sneak through otherwise, but it would be useful to have the time of the freeze to hack on badges infrastructure, to test things.. double-test things: be in a better position.

Although we're not quite ready to use it just yet, I'd like to request badges01-{web,backend} in both stg and prod -- that way we can hack throughout the freeze. If I can help create the nodes, please let me know. :)

I think you haven't shifted your calendar by a week due to the 1 week slip at alpha. ;)

The final freeze should be starting 2013-06-18 unless I missed something.

So, hopefully you have some more time, but I will get things setup soon...

badges-backend01.stg and badges-web01.stg should be setup in ansible now.

We will need to hook up the proxy in puppet, but otherwise it should be ready for testing.

Solved! https://badges.fedoraproject.org/