canonical-ci-engineering team mailing list archive

[Chris Johnston <chris.johnston@xxxxxxxxxxxxx>]

3

If we require any DB or anything else that 'comes with' django then use
django. I don't want to get into the business of writing migrations and
such. I'd still prefer to just stick to one technology, but I'm willing to
be flexable for some of the very small services that may not need something
like a DB.
On Dec 4, 2013 6:03 PM, "Andy Doan" <andy.doan@xxxxxxxxxxxxx> wrote:

> We've debated some and at this point in our schedule we've got to commit
> to something for better or worse.
>
> The initial thought was using Django. Recently, I've seen others are using
> a more lightweight combo of gunicorn+restish. We felt tied to Django, but
> it seems there's enough precedence of non-django apps that its up to us to
> decide what we want.
>
> I flip-flop between the two. When thinking of the project-manager, I lean
> on Django. When looking at the branch/source builder, I lean to
> gunicorn+restish. I don't have a big opinion. I'd even be up for using
> both. However, that would probably just make us have this argument many
> more times instead of settling it once. I don't believe either option is
> going to make our lives significantly better or worse.
>
> I propose a simple majority vote and move on. I want to get back to
> prototyping ASAP. Valid votes should be:
>
>  1) django
>  2) gunicorn + restish
>  3) both
>
> If no responses or consensus is reached, then I vow to drink 6 beers,
> re-read this email, and make a unilateral decision.
>
> I'm about 51% in favor of one of the options, but I don't want to sway
> anyone. Instead, I'll list some pros/cons I've thought about:
>
> = Django
> Pros:
>  * I've seen this scale well beyond what the airlines will become
>  * built-in support for user authentication and authorization
>  * built-in support for DB schema changes
>  * works near transparently with tastypie for REST (if you have a
>    models.py, then you'll have a REST API in minutes)
>
> Cons:
>  * Many of our services don't need core django features. ie:
>    * no web-ui's are needed
>    * no DB's for a few (which means more effort for REST interfaces)
>  * it might be harder to charm well (by I/S standards)
>
> Red Herrings:
>  * Heavy-weight - my 3 year old beagleboard runs it. Its big, but it
>    requires very little disk, memory, or CPU.
>
> = Gunicorn + Restish
> Pros:
>  * Its very basic so its easy to understand
>  * Services like the click-package-index are using this approach, so
>    there's some code we can steal/(ab)use.
>
> Cons:
>  * DB access becomes psycop2 and you have to manage your own schema
>    migrations and db-setup.
>  * nothing like the django admin panel
>
> --
> Mailing list: https://launchpad.net/~canonical-ci-engineering
> Post to     : canonical-ci-engineering@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~canonical-ci-engineering
> More help   : https://help.launchpad.net/ListHelp
>