mantl-api panics when framework is nil

[ericsakowski]

Hi @ryane

When packages.json does not contain a value for "framework":, mantl-api panics with the following message:

2016/05/06 19:48:34 http: panic serving 10.192.71.109:57460: interface conversion: interface is nil, not bool
goroutine 5249 [running]:
net/http.(*conn).serve.func1(0xc8200ca160, 0x7f6c035380c0, 0xc8201142e0)
    /usr/lib/go/src/net/http/server.go:1287 +0xb5
github.com/CiscoCloud/mantl-api/install.packageCatalog.packagesIndex(0xc8201d8240, 0xc820192048, 0x0, 0x0, 0x0, 0x0, 0x0)
    /go/src/github.com/CiscoCloud/mantl-api/install/catalog.go:82 +0x631
github.com/CiscoCloud/mantl-api/install.(*Install).getPackages(0xc8204db1a0, 0x0, 0x0, 0x0, 0x0, 0x0)
    /go/src/github.com/CiscoCloud/mantl-api/install/package.go:324 +0xb2
github.com/CiscoCloud/mantl-api/install.(*Install).getPackageByName(0xc8204db1a0, 0xc820136110, 0x7, 0x0, 0x0, 0x0)
    /go/src/github.com/CiscoCloud/mantl-api/install/package.go:328 +0x42
github.com/CiscoCloud/mantl-api/install.(*Install).Package(0xc8204db1a0, 0xc820136110, 0x7, 0x9a1f98, 0x0, 0x0)
    /go/src/github.com/CiscoCloud/mantl-api/install/install.go:62 +0x41
github.com/CiscoCloud/mantl-api/api.(*Api).describePackage(0xc8201db600, 0x7f6c035940d0, 0xc8200ca210, 0xc8204f42a0, 0xc820136180, 0x1, 0x1)
    /go/src/github.com/CiscoCloud/mantl-api/api/api.go:99 +0xe4
github.com/CiscoCloud/mantl-api/api.(*Api).(github.com/CiscoCloud/mantl-api/api.describePackage)-fm(0x7f6c035940d0, 0xc8200ca210, 0xc8204f42a0, 0xc820136180, 0x1, 0x1)
    /go/src/github.com/CiscoCloud/mantl-api/api/api.go:62 +0x5c
github.com/julienschmidt/httprouter.(*Router).ServeHTTP(0xc820011a80, 0x7f6c035940d0, 0xc8200ca210, 0xc8204f42a0)
    /go/src/github.com/julienschmidt/httprouter/router.go:344 +0x195
github.com/CiscoCloud/mantl-api/api.logHandler.func1(0x7f6c035940d0, 0xc8200ca210, 0xc8204f42a0)
    /go/src/github.com/CiscoCloud/mantl-api/api/api.go:43 +0x1a4
net/http.HandlerFunc.ServeHTTP(0xc8201db760, 0x7f6c035940d0, 0xc8200ca210, 0xc8204f42a0)
    /usr/lib/go/src/net/http/server.go:1422 +0x3a
net/http.serverHandler.ServeHTTP(0xc8204ee060, 0x7f6c035940d0, 0xc8200ca210, 0xc8204f42a0)
    /usr/lib/go/src/net/http/server.go:1862 +0x19e
net/http.(*conn).serve(0xc8200ca160)
    /usr/lib/go/src/net/http/server.go:1361 +0xbee
created by net/http.(*Server).Serve
    /usr/lib/go/src/net/http/server.go:1910 +0x3f6

on the customer end of the connection this appears as a 502 Bad Gateway error.

The problem mesosphere universe repos are:
./repo/packages/M/mysql/0/package.json
./repo/packages/M/mysql/1/package.json
./repo/packages/M/marathon-lb/0/package.json
./repo/packages/M/marathon-lb/1/package.json
./repo/packages/M/marathon-lb/4/package.json
./repo/packages/M/marathon-lb/2/package.json
./repo/packages/M/marathon-lb/3/package.json
./repo/packages/M/marathon/1/package.json
./repo/packages/M/marathon/2/package.json
./repo/packages/L/linkerd/0/package.json
./repo/packages/L/linkerd/1/package.json
./repo/packages/O/openvpn/0/package.json
./repo/packages/O/openvpn-admin/0/package.json
./repo/packages/N/nginx/0/package.json
./repo/packages/N/nginx/1/package.json
./repo/packages/N/namerd/0/package.json
./repo/packages/N/namerd/1/package.json
./repo/packages/W/weavescope/0/package.json
./repo/packages/W/weavescope-probe/0/package.json

I'm on rev 8783d7621439a3211d55ce5e22c128ee04a91d47 of mesosphere/universe and rev 1abaf95 of mantl-api.

I'd be happy to submit a PR for this, but before I do, would you prefer setting meta["framework"] to false if it is nil (with a warning) by wrapping https://github.com/CiscoCloud/mantl-api/blob/master/install/catalog.go#L82 inside an if block, OR should I wrap the whole of the package processing inside a test on err that warns on error but continues to the next package? I think the 2nd option might be more useful and would probably help close out #41 as well.

[ryane]

actually, I am thinking we should do both. if framework is not going to be a required field, it might make sense to just default it to false if it does not exist in the package.json. But, not panicking on an otherwise invalid package is pretty important too.