ppa-assigner: private_only is hardcoded and confusing

[Evan]

private_only is set to False in unit_config, however it needs to be set to True for a pool of private PPAs to work at all. It's name is confusing. As currently implemented, it being set to false does not produce a full set of PPAs, regardless of whether they're public or private. Instead, setting it false only produces a set of public PPAs.

Because it's currently hardcoded, we need to hack in that setting to True before deploying with private PPAs.

Original report follows:
I noticed on a fresh deploy, a ticket I submitted sat in the pending state for ages. I exposed jenkins and had a look:

11:15:24 INFO lander_service_wrapper: Calling via POST [http://10.0.0.243:8080/api/v1/ppa/]: {'ticket_id': u'1'}
11:15:24 WARNING root: No free PPAs can be found. Retrying in 120s

Okay, that seemed odd, but sure enough this was the case:

curl --dump-header - -H "Content-Type: application/json" http://10.0.0.243:8080/api/v1/ppa/ -X POST --data '{"ticket_id": 1}'

HTTP/1.1 404 NOT FOUND
Server: gunicorn/0.13.4
Date: Fri, 14 Mar 2014 11:13:16 GMT
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

No free PPAs exist in pool

Now, the weird part is that none of these PPAs are marked as unavailable in the database:

{
    "meta": {
        "limit": 20,
        "next": null,
        "offset": 0,
        "previous": null,
        "total_count": 6
    },
    "objects": [
        {
            "id": 1,
            "name": "ppa:ci-engineering-<redacted>-2/ci-pool-2-001",
            "private": true,
            "resource_uri": "/api/v1/ppa/1/",
            "state": 0,
            "ticket_id": 0,
            "timestamp": "2014-03-14T09:55:41.688596"
        },
        {
            "id": 2,
            "name": "ppa:ci-engineering-<redacted>-2/ci-pool-2-003",
            "private": true,
            "resource_uri": "/api/v1/ppa/2/",
            "state": 0,
            "ticket_id": 0,
            "timestamp": "2014-03-14T09:55:41.690413"
        },
        {
            "id": 3,
            "name": "ppa:ci-engineering-<redacted>-2/ci-pool-2-002",
            "private": true,
            "resource_uri": "/api/v1/ppa/3/",
            "state": 0,
            "ticket_id": 0,
            "timestamp": "2014-03-14T09:55:41.691897"
        },
        {
            "id": 4,
            "name": "ppa:ci-engineering-<redacted>-2/ci-pool-2-005",
            "private": true,
            "resource_uri": "/api/v1/ppa/4/",
            "state": 0,
            "ticket_id": 0,
            "timestamp": "2014-03-14T09:55:41.693143"
        },
        {
            "id": 5,
            "name": "ppa:ci-engineering-<redacted>-2/ci-pool-2-004",
            "private": true,
            "resource_uri": "/api/v1/ppa/5/",
            "state": 0,
            "ticket_id": 0,
            "timestamp": "2014-03-14T09:55:41.694276"
        },
        {
            "id": 6,
            "name": "ppa:ci-engineering-<redacted>-2/ci-pool-2-006",
            "private": true,
            "resource_uri": "/api/v1/ppa/6/",
            "state": 0,
            "ticket_id": 0,
            "timestamp": "2014-03-14T09:55:41.695418"
        }
    ]
}

[Andy Doan (doanac)]

For now, I think we should make the private-ppa option configurable at deployment time with something like:

 # unit-config.yaml.tmpl:
 private_only: $CI_PRIVATE_PPAS

then deploy.py can default that variable to False and add a new arparse option for "--private-ppas"

[Ursula Junque (ursinha)]

If you take a look at the code, you'll see that the PPAs are never marked as available or unavailable based on privacy, but reserve() only returns PPAs available that respect that setting.

I'm implementing the change suggested by Andy.