canonical/jujucharms.com#1

We want to verify that this is ok in the latest QA and that 4.0.1 will in fact work for this.

See the example:
https://api.jujucharms.com/charmstore/v4/~kubernetes/bundle/kubernetes-cluster-2/archive/bundle.yaml

http://bazaar.launchpad.net/~kubernetes/charms/bundles/kubernetes-cluster/bundle/view/head:/bundles.yaml

Fixing this bug needs to have a migration to update any existing bundles that this got added to so that they will work without requiring a fresh upload from all bundle authors.

Right now you cannot search for bundles via text at all. Searching for mongodb-cluster returns many charms but no bundles.

http://juju.mycomiclife.net/cs/v4/search?text=mongodb-cluster&limit=100

{"SearchTime":9000000,"Total":239,"Results":[{"Id":"cs:~justin-fathomdb/trusty/mongodb-proxy-0"},{"Id":"cs:~niemeyer/precise/build-mongo-0"},{"Id":"cs:~niemeyer/precise/build-mongodb-0"},{"Id":"cs:~lazypower/precise/errbit-0"},{"Id":"cs:~lazypower/precise/errbit-1"},{"Id":"cs:~lazypower/precise/errbit-2"},{"Id":"cs:precise/opentsdb-1"},{"Id":"cs:precise/opentsdb-2"},{"Id":"cs:precise/opentsdb-3"},{"Id":"cs:~ju-jistics-hackers/precise/logall-subordinate-0"},{"Id":"cs:~lifeless/precise/opentsdb-2"},{"Id":"cs:~lifeless/precise/opentsdb-0"},{"Id":"cs:~lifeless/precise/opentsdb-1"},{"Id":"cs:~charmers/precise/opentsdb-3"},{"Id":"cs:~charmers/precise/opentsdb-0"},{"Id":"cs:~charmers/precise/opentsdb-1"},{"Id":"cs:~charmers/precise/opentsdb-2"},{"Id":"cs:oneiric/hadoop-slave-0"},{"Id":"cs:oneiric/hadoop-mapreduce-1"},{"Id":"cs:precise/nvp-transport-node-0"},{"Id":"cs:precise/nvp-transport-node-1"},{"Id":"cs:precise/nvp-transport-node-2"},{"Id":"cs:precise/nvp-transport-node-3"},{"Id":"cs:precise/nvp-transport-node-4"},{"Id":"cs:precise/nvp-transport-node-5"},{"Id":"cs:~openstack-charmers/trusty/percona-cluster-4"},{"Id":"cs:~openstack-charmers/trusty/percona-cluster-5"},{"Id":"cs:~openstack-charmers/trusty/percona-cluster-6"},{"Id":"cs:~openstack-charmers/trusty/percona-cluster-7"},{"Id":"cs:~openstack-charmers/trusty/percona-cluster-8"},{"Id":"cs:~openstack-charmers/trusty/percona-cluster-0"},{"Id":"cs:~openstack-charmers/trusty/percona-cluster-1"},{"Id":"cs:~openstack-charmers/trusty/percona-cluster-2"},{"Id":"cs:~openstack-charmers/trusty/percona-cluster-3"},{"Id":"cs:~openstack-charmers/precise/percona-cluster-10"},{"Id":"cs:~openstack-charmers/precise/percona-cluster-11"},{"Id":"cs:~openstack-charmers/precise/percona-cluster-5"},{"Id":"cs:~openstack-charmers/precise/percona-cluster-6"},{"Id":"cs:~openstack-charmers/precise/percona-cluster-7"},{"Id":"cs:~openstack-charmers/precise/percona-cluster-8"},{"Id":"cs:~openstack-charmers/precise/percona-cluster-9"},{"Id":"cs:~openstack-charmers/precise/percona-cluster-0"},{"Id":"cs:~openstack-charmers/precise/percona-cluster-1"},{"Id":"cs:~openstack-charmers/precise/percona-cluster-2"},{"Id":"cs:~openstack-charmers/precise/percona-cluster-3"},{"Id":"cs:~openstack-charmers/precise/percona-cluster-4"},{"Id":"cs:oneiric/cf-mongodb-0"},{"Id":"cs:oneiric/ceph-0"},{"Id":"cs:~charmers/precise/hadoop-mapreduce-0"},{"Id":"cs:~charmers/precise/hadoop-mapreduce-1"},{"Id":"cs:~charmers/precise/hadoop-slave-0"},{"Id":"cs:~charmers/precise/hadoop-slave-1"},{"Id":"cs:~charmers/oneiric/hadoop-mapreduce-0"},{"Id":"cs:~charmers/oneiric/hadoop-mapreduce-1"},{"Id":"cs:~charmers/oneiric/hadoop-slave-0"},{"Id":"cs:~openstack-charmers/trusty/nsx-transport-node-0"},{"Id":"cs:~james-page/precise/nvp-transport-node-34"},{"Id":"cs:~james-page/precise/nvp-transport-node-35"},{"Id":"cs:~james-page/precise/nvp-transport-node-36"},{"Id":"cs:~james-page/precise/nvp-transport-node-37"},{"Id":"cs:~james-page/precise/nvp-transport-node-25"},{"Id":"cs:~james-page/precise/nvp-transport-node-26"},{"Id":"cs:~james-page/precise/nvp-transport-node-27"},{"Id":"cs:~james-page/precise/nvp-transport-node-28"},{"Id":"cs:~james-page/precise/nvp-transport-node-29"},{"Id":"cs:~james-page/precise/nvp-transport-node-30"},{"Id":"cs:~james-page/precise/nvp-transport-node-31"},{"Id":"cs:~james-page/precise/nvp-transport-node-32"},{"Id":"cs:~james-page/precise/nvp-transport-node-33"},{"Id":"cs:~james-page/precise/nvp-transport-node-16"},{"Id":"cs:~james-page/precise/nvp-transport-node-17"},{"Id":"cs:~james-page/precise/nvp-transport-node-18"},{"Id":"cs:~james-page/precise/nvp-transport-node-19"},{"Id":"cs:~james-page/precise/nvp-transport-node-20"},{"Id":"cs:~james-page/precise/nvp-transport-node-21"},{"Id":"cs:~james-page/precise/nvp-transport-node-22"},{"Id":"cs:~james-page/precise/nvp-transport-node-23"},{"Id":"cs:~james-page/precise/nvp-transport-node-24"},{"Id":"cs:~james-page/precise/nvp-transport-node-10"},{"Id":"cs:~james-page/precise/nvp-transport-node-11"},{"Id":"cs:~james-page/precise/nvp-transport-node-12"},{"Id":"cs:~james-page/precise/nvp-transport-node-13"},{"Id":"cs:~james-page/precise/nvp-transport-node-14"},{"Id":"cs:~james-page/precise/nvp-transport-node-15"},{"Id":"cs:~james-page/precise/nvp-transport-node-4"},{"Id":"cs:~james-page/precise/nvp-transport-node-5"},{"Id":"cs:~james-page/precise/nvp-transport-node-6"},{"Id":"cs:~james-page/precise/nvp-transport-node-7"},{"Id":"cs:~james-page/precise/nvp-transport-node-8"},{"Id":"cs:~james-page/precise/nvp-transport-node-9"},{"Id":"cs:~james-page/precise/nvp-transport-node-0"},{"Id":"cs:~james-page/precise/nvp-transport-node-1"},{"Id":"cs:~james-page/precise/nvp-transport-node-2"},{"Id":"cs:~james-page/precise/nvp-transport-node-3"},{"Id":"cs:~charmers/precise/nvp-transport-node-5"},{"Id":"cs:~charmers/precise/nvp-transport-node-0"},{"Id":"cs:~charmers/precise/nvp-transport-node-1"},{"Id":"cs:~charmers/precise/nvp-transport-node-2"},{"Id":"cs:~charmers/precise/nvp-transport-node-3"},{"Id":"cs:~charmers/precise/nvp-transport-node-4"}]}

Looking at

http://juju.mycomiclife.net/cs/v4/mongodb-cluster/archive/bundle.yaml

the top section of the bundles.yaml which houses the name of the bundle is truncated.

The original is at
http://bazaar.launchpad.net/~charmers/charms/bundles/mongodb-cluster/bundle/view/head:/bundles.yaml

The archive includes a .orig, but this means that grabbing the bundles.yaml from the api is not close enough to tell where it came from, what the bundle name is, etc. We should keep that first section.

Legacy data for download counts show a lot of activity that we did not include in the new charmstore.

See counts on http://manage.jujucharms.com/charms/trusty/wordpress vs https://api.jujucharms.com/v4/trusty/wordpress/meta/any?include=stats

While there are good reasons to reset the count, this has led to a lot of negative feedback about the zero counts.

id/meta/charm-metadata doesn't include the maintainer parameter; likewise it cannot be found via the /meta endpoint.

It looks like this information isn't pulled in during ingest.

The charm has it in charm-metadata:
https://api.jujucharms.com/v4/mongodb/meta/charm-metadata

However bundles don't have it though it's in the charmworld data:
https://api.jujucharms.com/v4/~jcsackett/bundle/mongodb-cluster-0/meta/bundle-metadata
http://manage.jujucharms.com/api/3/search?text=jcsackett

Compare the YAML file https://api.jujucharms.com/v4/trusty/glance-12/archive/metadata.yaml with the response from the api: https://api.jujucharms.com/charmstore/v4/precise/glance-39/meta/any?include=charm-related .

When this fix goes out the GUI will need to be updated along with any other consumers of this endpoint.

See:
https://api.jujucharms.com/v4/mediawiki-scalable-1768/meta/archive-upload-time
https://api.jujucharms.com/v4/mediawiki-scalable-1769/meta/archive-upload-time
https://api.jujucharms.com/v4/mediawiki-scalable-1771/meta/archive-upload-time

Also:
https://api.jujucharms.com/v4/mediawiki-scalable/meta/revision-info

I think the charmstore database name "juju" can be confused with the same database name used by the Juju state server.

I propose changing the name. Could be "charmstore" or "frosted-lucky-charms"... anything but "juju".

We need to be able to perform a search and sort by for the UI. This will be especially important when we start working out a pagination strategy.

Name (alphabetise A-Z)
Owner (alphabetise A-Z)
Deploys (descending order 100-1)
Units (descending order 100-1)
Series (Latest to oldest)

We have no means of getting the bzr information (formerly in code_source in charmworld). The spec specifically indicates this isn't going to be implemented, but there are clients of the charmstore that need this information.

https://api.jujucharms.com/charmstore/v4/~hloeung/precise/apache2-2/icon.svg returns with a 500 and the body content of
{"Message":"failed to read token: XML syntax error on line 3: invalid UTF-8","Code":""} which causes a broken image when viewed in the GUI. Charmstore should probably return the default image if there are any issues with the svg's

https://jujucharms.com/mysql/precise/28 fails to load further information on the bundles because there are a million versions of mediawiki-scalable. We should only return the latest version per solution.

As like charms, bundles should support being categorized by multiple categorized.

When querying the charmstore api with something like:

charm info hdp-hadoop

The resulting yaml is: http://paste.ubuntu.com/14404910/

My hope was to see one of the bundles that contain this charm as seen on https://jujucharms.com/big-data under the Hadoop core batch processing section (juju quickstart hdp-core-batch-processing). Currently bundles-containing field for this entry is empty. Am I missing something or is there a current issue with pulling bundles-containing due to some sort of version constraint?

In new production with new ingestion the /solutions page failed to load content due to the owner= on the api request.

After a fresh ingestion any owner on the api will fail to return results.

https://api.jujucharms.com/v4/search?series=trusty&owner=&limit=600

Failed to return any results.

Grabbing the owner into a Attribution file that's included with the bundles.yaml and the README

https://api.jujucharms.com/charmstore/v4/changes/published?from=20-05-2015&to=21-05-15

It's got ~charmers/cassandra with all the revisions spread across it.

We need to resolve the license contention in this project to put juju 1.24.2 into Ubuntu.

Either csclient/* are AGPL, or the LGPLv3 license needs to be added and the files point to it.

The endpoints listed in the readme are the old charmstore endpoints--there's no documentation in the readme of the new endpoints.

We need a means of determining, provided e.g. 'mysql', what charm-id will actually be deployed e.g. 'cs:trusty/mysql-7'; also provided 'precise/mysql' which revno will be deployed e.g. 'cs:precise/mysql-48'

The current API provides expand-id, which gives us all possible IDs lexicographically sorted -- the same list for both cases. We can work with that for now, but it requires a lot of processing on the client end. There should be a means of determining what the actual deployed version will be based on either of those partial id patterns.

This may not be part of expand-id, but it should exist somewhere in reasonably accessible form.

On the debug/status page there are many places where a date and time are reported. On that one result, the following formats are used:

2015-03-05T09:12:07-04:00
0001-01-01T00:00:00Z
2015-03-05 13:08:44.8833498 +0000 UTC

The second one is clearly not populated so perhaps it can be ignored. The first one is a reasonable format but is shown in localtime with TZ offset. Showing times in UTC would be better. The third is overly precise.

Unless there is a specific reason for an exception, we should strive to have all user-visible dates similarly formatted and presented in UTC.

bac@chuleta:~/go/src/github.com/juju/charmstore$ http localhost:8080/v4/debug/status
HTTP/1.1 200 OK
Access-Control-Allow-Headers: X-Requested-With
Access-Control-Allow-Origin: *
Content-Length: 1210
Content-Type: application/json
Date: Thu, 05 Mar 2015 13:27:07 GMT

{
"base_entities": {
"Duration": 424160,
"Name": "Base entities in charm store",
"Passed": true,
"Value": "count: 17"
},
"elasticsearch": {
"Duration": 3944280,
"Name": "Elastic search is running",
"Passed": false,
"Value": "cluster_name: elasticsearch, status: yellow, timed_out: false, number_of_nodes: 1, number_of_data_nodes: 1, active_primary_shards: 13, active_shards: 13, relocating_shards: 0, initializing_shards: 0, unassigned_shards:13"
},
"entities": {
"Duration": 7206240,
"Name": "Entities in charm store",
"Passed": true,
"Value": "196 charms; 0 bundles; 78 promulgated"
},
"ingestion": {
"Duration": 495600,
"Name": "Ingestion",
"Passed": true,
"Value": "started: 2015-03-05T09:12:07-04:00, completed: 2015-03-05T09:22:36-04:00"
},
"legacy_statistics": {
"Duration": 240920,
"Name": "Legacy Statistics Load",
"Passed": false,
"Value": "started: 0001-01-01T00:00:00Z, completed: 0001-01-01T00:00:00Z"
},
"mongo_collections": {
"Duration": 894520,
"Name": "MongoDB collections",
"Passed": true,
"Value": "All required collections exist"
},
"mongo_connected": {
"Duration": 263800,
"Name": "MongoDB is connected",
"Passed": true,
"Value": "Connected"
},
"server_started": {
"Duration": 15200,
"Name": "Server started",
"Passed": true,
"Value": "2015-03-05 13:08:44.8833498 +0000 UTC"
}
}

When expand-id is called on a bundle, we return charms with the same name as well. This will not be a problem with a flat namespace, as such collisions will not be allowed.

Example:

% charmd config.yaml
no reachable servers

This should say that it's trying to connect to mongo.
Easily fixed by adding annotations to the errors returns in main.serve.

See bug: canonical/jujucharms.com#78

note that the first link is a real file and the second is a symlink to a script.

In looking at the manifest there's no way to really confirm a file is a symlink (they all happen to be 15 bytes)

https://api.jujucharms.com/charmstore/v4/trusty/mysql-24/meta/manifest

It might be nice to have a 'LinksTo" or something in the manifest and/or investigate 302'ing from the one file to the symlink location in the api.

Doing this call on the API:

http://juju.mycomiclife.net/cs/v4/search?text=wordpress&include=archive-size

Does not return the included meta data, only the IDs. Per the spec and for storefront we need to have the ability to get the metadata so we don't have to make multiple calls.

I used juju charm create test and changed nothing, then cd test; zip -ur ../test.zip . and tried to upload.

HTTP/1.1 500 Internal Server Error
Access-Control-Allow-Headers: X-Requested-With
Access-Control-Allow-Origin: *
Content-Length: 134
Content-Type: application/json
Date: Thu, 07 May 2015 13:25:25 GMT

{
    Message: "interface interface-name in relation provides-relation has almost certainly not been changed from the template"
    Code: ""
}

I'd expect a 400 level error instead of a 500 level error. Maybe a 422 or a 400.

http://juju.mycomiclife.net/cs/v4/mongodb/meta/any?include=charm-metadata

I was told that we auto turned categories into tags. This might have been scoped to just searching? It needs to be done completely so that in the api we can see Tags and not Categories.

Ecosystem is working on moving the fields, but it'll take time. They're also working on updating to the whitelisted list. We should make sure to ignore tags not in the white list.

The initial set of whitelisted tags are:

analytics                                                                                                                                                                                                                                      
big_data                                                                                                                                                                                                                                       
ecommerce                                                                                                                                                                                                                                      
openstack                                                                                                                                                                                                                                      
cloudfoundry                                                                                                                                                                                                                                   
cms                                                                                                                                                                                                                                            
social                                                                                                                                                                                                                                         
streaming                                                                                                                                                                                                                                      
wiki                                                                                                                                                                                                                                           
ops                                                                                                                                                                                                                                            
backup                                                                                                                                                                                                                                         
identity                                                                                                                                                                                                                                       
monitoring                                                                                                                                                                                                                                     
performance                                                                                                                                                                                                                                    
audits                                                                                                                                                                                                                                         
security                                                                                                                                                                                                                                       
network                                                                                                                                                                                                                                        
storage                                                                                                                                                                                                                                        
database                                                                                                                                                                                                                                       
cache (or cache-proxy?)                                                                                                                                                                                                                        
development (rails, django, etc.)                                                                                                                                                                                                  
web_server                                                                                                                                                                                                                                     

https://api.jujucharms.com/v4/~cf-charmers/trusty/collector-v1-0/icon.svg returns 404 instead of the default icon

https://api.jujucharms.com/v4/~cf-charmers/trusty/collector-v1-0 (not found)
https://api.jujucharms.com/v4/~cf-charmers/trusty/collector-v1-0/meta/any (id found)
https://api.jujucharms.com/v4/~cf-charmers/trusty/collector-v1-0/meta/any?include=manifest (none matching)

from: https://bugs.launchpad.net/charmworld/+bug/1390127

https://manage.jujucharms.com/api/3/search?type=approved&series=trusty&limit=1000

https://api.jujucharms.com/v4/search?series=trusty&owner=&limit=600

URLs:
http get https://api.jujucharms.com/v4/trusty/landscape-client/meta/extra-info
http get https://api.jujucharms.com/v4/~landscape-charmers/trusty/landscape-client/meta/extra-info

(replace with local URL after ingestion)

Using ingestion on local machine, this is the output of the process [1], also available at [*]. Ingestion puts all that is required in extra-info for both ~landscape-charmers/trusty/landscape-client-10 and to /trusty/landscape-client-10. However, looking at /meta/extra info for ~landscape-charmers [2] vs promulgated [3], we see a difference. The ~landscape-charmers end up with revision 37, while promulgated ends up with 46.

There is more:
On staging and production, the difference in revisions between ~landscape-charmers and promulgated remains, however, on production, the latest revision is marked at 44 and not 46.

[1]
https://pastebin.canonical.com/122985/

[2]
https://pastebin.canonical.com/122988/

[3]
https://pastebin.canonical.com/122989/

[*]
2015-01-08 11:51:48 INFO charmload lpad.go:714 uploaded cs:~landscape-charmers/trusty/landscape-client-10
2015-01-08 11:51:48 DEBUG charmload lpad.go:763 PUT http://localhost:8080/v4/~landscape-charmers/trusty/landscape-client-10/meta/extra-info/ lppublish.extraInfoParams{Digest:"[email protected]", BranchURL:"lp:~landscape-charmers/charms/trusty/landscape-client/trunk", Owner:"landscape-charmers", Revisions:[]lppublish.revision{lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Adam Collard"}}, Date:"2014-03-10T12:22:46Z", Message:"Merged ssl-certificate-confusion [r=tribaal,ack] [f=1287711].\n\nEnsure that we always try to decode the base64 encoded ssl key whenever we write the configuration, not just in registration-relation-{joined,changed}\n", Revno:37}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"David Britton"}}, Date:"2014-01-28T18:30:49Z", Message:"Merging in 1273788-change-relation-interface [f=1273788] [r=andreas,csmith]\n", Revno:36}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Bjorn Tillenius"}}, Date:"2013-12-09T12:39:55Z", Message:"Merged relation-depart-no-register [r=adam-collard,tribaal] [f=1255972].\n\nClear relation data when departing the relation.\n\nDelete all data related to the container relation when departing it. The\ncomputer title and the juju info file contains information about the remote\nunit that landscape-client is related to. If the relation is removed, that\ninformation is not valid anymore and should be removed.\n\nThis prevents the client from trying to register again when the config-changed\nhook is run, which can happen when services are destroyed.\n\nI also changed the way hooks are run, so that tests and the real Juju process\nruns hooks the same way.\n", Revno:35}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Andreas Hasenack"}}, Date:"2013-11-28T20:57:01Z", Message:"Merged fix-registration-relation [r=jseutter] [f=1256109]\n\nFixed call to config_changed() in the registration relation.\n", Revno:34}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Adam Collard"}}, Date:"2013-11-20T09:37:23Z", Message:"Merged fix-ceph-relation-error [r=bjornt,tealeg][a=adam-collard]\n\nMove ceph-relation-changed and ceph-relation-broken hooks into hooks.py and therefore more easily testable.\n", Revno:33}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Bjorn Tillenius"}}, Date:"2013-11-11T07:28:14Z", Message:"Fix ceph-client-relation-joined, which was pointing to the wrong file.", Revno:32}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Bjorn Tillenius"}}, Date:"2013-11-08T16:01:57Z", Message:"Make sure the juju-info file is written to disk before trying to\nregister the client with the server, so that information about the\nJuju environment is sent to the server at registration time.\n", Revno:31}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Bjorn Tillenius"}}, Date:"2013-11-07T15:41:45Z", Message:"Add a basic test for the container-relation-joined relation.\n\nThe purpose of this branch isn't to add full test coverage for the\ncontainer-relation-joined relation. It's to make it possible to add\ntests for this hooks (and other hooks as well, of course). I added a\nsimple test to show that it's indeed possible to test it.\n", Revno:30}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"James Page"}}, Date:"2013-10-28T12:42:21Z", Message:"[Andreas Hasenack] Improve the docs about SSL a bit.\n", Revno:29}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Adam Collard"}}, Date:"2013-10-14T08:15:41Z", Message:"Merged lp:~adam-collard/charms/precise/landscape-client/upgrade-charm-hook [r=free.ekanayaka,bjornt]\n\nAdd an upgrade-charm hook which will move any Juju information found in the old metadata.d directory into the new juju-info.json file.\n", Revno:28}}}
2015-01-08 11:51:48 DEBUG charmload lpad.go:593 extra-info for cs:~landscape-charmers/trusty/landscape-client-10 set to lppublish.extraInfoParams{Digest:"[email protected]", BranchURL:"lp:~landscape-charmers/charms/trusty/landscape-client/trunk", Owner:"landscape-charmers", Revisions:[]lppublish.revision{lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Adam Collard"}}, Date:"2014-03-10T12:22:46Z", Message:"Merged ssl-certificate-confusion [r=tribaal,ack] [f=1287711].\n\nEnsure that we always try to decode the base64 encoded ssl key whenever we write the configuration, not just in registration-relation-{joined,changed}\n", Revno:37}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"David Britton"}}, Date:"2014-01-28T18:30:49Z", Message:"Merging in 1273788-change-relation-interface [f=1273788] [r=andreas,csmith]\n", Revno:36}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Bjorn Tillenius"}}, Date:"2013-12-09T12:39:55Z", Message:"Merged relation-depart-no-register [r=adam-collard,tribaal] [f=1255972].\n\nClear relation data when departing the relation.\n\nDelete all data related to the container relation when departing it. The\ncomputer title and the juju info file contains information about the remote\nunit that landscape-client is related to. If the relation is removed, that\ninformation is not valid anymore and should be removed.\n\nThis prevents the client from trying to register again when the config-changed\nhook is run, which can happen when services are destroyed.\n\nI also changed the way hooks are run, so that tests and the real Juju process\nruns hooks the same way.\n", Revno:35}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Andreas Hasenack"}}, Date:"2013-11-28T20:57:01Z", Message:"Merged fix-registration-relation [r=jseutter] [f=1256109]\n\nFixed call to config_changed() in the registration relation.\n", Revno:34}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Adam Collard"}}, Date:"2013-11-20T09:37:23Z", Message:"Merged fix-ceph-relation-error [r=bjornt,tealeg][a=adam-collard]\n\nMove ceph-relation-changed and ceph-relation-broken hooks into hooks.py and therefore more easily testable.\n", Revno:33}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Bjorn Tillenius"}}, Date:"2013-11-11T07:28:14Z", Message:"Fix ceph-client-relation-joined, which was pointing to the wrong file.", Revno:32}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Bjorn Tillenius"}}, Date:"2013-11-08T16:01:57Z", Message:"Make sure the juju-info file is written to disk before trying to\nregister the client with the server, so that information about the\nJuju environment is sent to the server at registration time.\n", Revno:31}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Bjorn Tillenius"}}, Date:"2013-11-07T15:41:45Z", Message:"Add a basic test for the container-relation-joined relation.\n\nThe purpose of this branch isn't to add full test coverage for the\ncontainer-relation-joined relation. It's to make it possible to add\ntests for this hooks (and other hooks as well, of course). I added a\nsimple test to show that it's indeed possible to test it.\n", Revno:30}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"James Page"}}, Date:"2013-10-28T12:42:21Z", Message:"[Andreas Hasenack] Improve the docs about SSL a bit.\n", Revno:29}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Adam Collard"}}, Date:"2013-10-14T08:15:41Z", Message:"Merged lp:~adam-collard/charms/precise/landscape-client/upgrade-charm-hook [r=free.ekanayaka,bjornt]\n\nAdd an upgrade-charm hook which will move any Juju information found in the old metadata.d directory into the new juju-info.json file.\n", Revno:28}}}
2015-01-08 11:51:48 INFO charmload lpad.go:714 uploaded cs:trusty/landscape-client-10
2015-01-08 11:51:48 DEBUG charmload lpad.go:763 PUT http://localhost:8080/v4/trusty/landscape-client-10/meta/extra-info/ lppublish.extraInfoParams{Digest:"[email protected]", BranchURL:"lp:~landscape-charmers/charms/trusty/landscape-client/trunk", Owner:"landscape-charmers", Revisions:[]lppublish.revision{lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"David Britton"}}, Date:"2014-12-17T23:57:11Z", Message:"sync merge history from trunk (no file differences) [trivial]\n", Revno:46}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"David Britton"}}, Date:"2014-12-17T23:51:37Z", Message:"Bringing precise client charm up to speed (trunk revisions r45-50).\n- lp:1399312\n- Testing improvments\n- legacy options dropped\n- charmhelpers resync\n", Revno:45}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Christopher Glass"}}, Date:"2014-08-28T10:10:52Z", Message:"Merge lp:~tribaal/charms/trusty/landscape-client/fix-unit-tests-take-two [r=free, sparkiegeek]\n", Revno:44}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Christopher Glass"}}, Date:"2014-08-22T09:16:00Z", Message:"Merging lp:~tribaal/charms/trusty/landscape-client/put-install-hook-in-its-own-file [r=sparkiegeek, fcorrea]\n\nThis moves the install hook to its own file to prevent import problems.\n", Revno:43}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Christopher Glass"}}, Date:"2014-08-15T17:07:39Z", Message:"Merge lp:~tribaal/charms/trusty/landscape-client/add-sync-makefile-target [r=ack, dpb]\n", Revno:42}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Christopher Glass"}}, Date:"2014-08-15T06:08:59Z", Message:"Merging lp:~jose/charms/precise/landscape-client/readme-to-markdown [r=dpb, tribaal][f=1239576]\n", Revno:41}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Christopher Glass"}}, Date:"2014-06-23T11:32:51Z", Message:"Merge lp:~tribaal/charms/trusty/landscape-client/additional-logging [r=sparkiegeek, free]\n", Revno:40}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Adam Collard"}}, Date:"2014-06-16T08:28:56Z", Message:"Merged landscape-client-multiple-juju-files [r=danilo,tealeg] [f=1325599].\n\nLet the charm output several juju-info JSON files instead of a single file, since the landscape client charm can be deployed to several machines that are "hulk-smashed" together on the same physical machine.\n", Revno:39}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Christopher Glass"}}, Date:"2014-06-12T11:41:33Z", Message:"Merge changes from the ~landscape/charms/landscape-client/trunk branch.\n", Revno:38}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Adam Collard"}}, Date:"2014-03-10T12:22:46Z", Message:"Merged ssl-certificate-confusion [r=tribaal,ack] [f=1287711].\n\nEnsure that we always try to decode the base64 encoded ssl key whenever we write the configuration, not just in registration-relation-{joined,changed}\n", Revno:37}}}
2015-01-08 11:51:48 DEBUG charmload lpad.go:593 extra-info for cs:trusty/landscape-client-10 set to lppublish.extraInfoParams{Digest:"[email protected]", BranchURL:"lp:~landscape-charmers/charms/trusty/landscape-client/trunk", Owner:"landscape-charmers", Revisions:[]lppublish.revision{lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"David Britton"}}, Date:"2014-12-17T23:57:11Z", Message:"sync merge history from trunk (no file differences) [trivial]\n", Revno:46}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"David Britton"}}, Date:"2014-12-17T23:51:37Z", Message:"Bringing precise client charm up to speed (trunk revisions r45-50).\n- lp:1399312\n- Testing improvments\n- legacy options dropped\n- charmhelpers resync\n", Revno:45}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Christopher Glass"}}, Date:"2014-08-28T10:10:52Z", Message:"Merge lp:~tribaal/charms/trusty/landscape-client/fix-unit-tests-take-two [r=free, sparkiegeek]\n", Revno:44}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Christopher Glass"}}, Date:"2014-08-22T09:16:00Z", Message:"Merging lp:~tribaal/charms/trusty/landscape-client/put-install-hook-in-its-own-file [r=sparkiegeek, fcorrea]\n\nThis moves the install hook to its own file to prevent import problems.\n", Revno:43}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Christopher Glass"}}, Date:"2014-08-15T17:07:39Z", Message:"Merge lp:~tribaal/charms/trusty/landscape-client/add-sync-makefile-target [r=ack, dpb]\n", Revno:42}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Christopher Glass"}}, Date:"2014-08-15T06:08:59Z", Message:"Merging lp:~jose/charms/precise/landscape-client/readme-to-markdown [r=dpb, tribaal][f=1239576]\n", Revno:41}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Christopher Glass"}}, Date:"2014-06-23T11:32:51Z", Message:"Merge lp:~tribaal/charms/trusty/landscape-client/additional-logging [r=sparkiegeek, free]\n", Revno:40}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Adam Collard"}}, Date:"2014-06-16T08:28:56Z", Message:"Merged landscape-client-multiple-juju-files [r=danilo,tealeg] [f=1325599].\n\nLet the charm output several juju-info JSON files instead of a single file, since the landscape client charm can be deployed to several machines that are "hulk-smashed" together on the same physical machine.\n", Revno:39}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Christopher Glass"}}, Date:"2014-06-12T11:41:33Z", Message:"Merge changes from the ~landscape/charms/landscape-client/trunk branch.\n", Revno:38}, lppublish.revision{Authors:[]lppublish.author{lppublish.author{Email:"[email protected]", Name:"Adam Collard"}}, Date:"2014-03-10T12:22:46Z", Message:"Merged ssl-certificate-confusion [r=tribaal,ack] [f=1287711].\n\nEnsure that we always try to decode the base64 encoded ssl key whenever we write the configuration, not just in registration-relation-{joined,changed}\n", Revno:37}}}
2015-01-08 11:51:48 DEBUG charmload lpad.go:266 done publishing URLs for cs:~landscape-charmers/trusty/landscape-client-10

Looking at Issue #222 it turned out that we do not ingest every possible charm and that some charms do not get promulgated (but should).

ElasticSearch for example.

• use charmload with --match=elasticsearch
• check all charms under ~charmers and then check all charms in global namespace.
  Most of the revisions are missing in the global namespace.

Our testing charmstore went down today, and so it was suggested that I run cs locally. These problems are ones that I ran into following the README doc, and so I'm filing these issues against that in particular. I don't have solutions/suggestions for all of them.

1. Running go get on the repo fetches master (v1), and make deps fails. Have to mkdir -p github.com/juju; git clone [email protected]:juju/charmstore.git, then run make deps; occasionally, I find myself having to git checkout v4 after a make step/go command switches me back to master.
2. Running make server leads the the cryptic no reachable servers. I finally consulted the oracle and this means that mongod isn't running, which isn't mentioned.
3. make sysdeps fails because elasticsearch is not signed and --force-yes is not provided to apt-get.
4. There are no instructions for ingesting any charms/bundles, and no fixtures provided, so now that I have a charmstore up and running, I can't do anything with it.

The GUI currently allows the user to upgrade from revno 0 to latest for all charms when the user clicks to 'Change version' Because not all revno's exist it would be nice if we could query a charmstore endpoint to get all available revision numbers that the user could up/downgrade to.

Related to issue #174, we need the name (e.g. "mongodb-cluster") to be in the bundle-metadata.

Currently it's not available, since that data is lost.

http://juju.mycomiclife.net/cs/v4/mongodb-cluster/meta/bundle-metadata

{"Services":{"configsvr":{"Charm":"cs:precise/mongodb-28","NumUnits":3,"Options":{"replicaset":"configsvr"},"Annotations":{"gui-x":"2528.00146484375","gui-y":"794.591796875"}},"mongos":{"Charm":"cs:precise/mongodb-28","NumUnits":1,"Annotations":{"gui-x":"2528.00341796875","gui-y":"1113.7550048828125"}},"shard1":{"Charm":"cs:precise/mongodb-28","NumUnits":3,"Options":{"replicaset":"shard1"},"Annotations":{"gui-x":"2163.205078125","gui-y":"1338.6932983398438"}},"shard2":{"Charm":"cs:precise/mongodb-28","NumUnits":3,"Options":{"replicaset":"shard2"},"Annotations":{"gui-x":"2530.71728515625","gui-y":"1448.6185913085938"}},"shard3":{"Charm":"cs:precise/mongodb-28","NumUnits":3,"Options":{"replicaset":"shard3"},"Annotations":{"gui-x":"2884.498291015625","gui-y":"1335.8310546875"}}},"Series":"precise","Relations":[["mongos:mongos","shard3:database"],["mongos:mongos-cfg","configsvr:configsvr"],["mongos:mongos","shard1:database"],["mongos:mongos","shard2:database"]]}

Base entities are never deleted, even if the last (or only) revision of the corresponding entities is deleted via the DELETE api call to the archive endpoint.
This can be problematic as the base entity stores, among other things, ACLs for related charms and bundles. So when the same entity is uploaded again it will automatically inherit the preexisting ACLs, which can be unexpected and confusing.

On http://juju.mycomiclife.net/cs/v4/~lazypower/precise/errbit-0/meta/extra-info

The extra-info parameter is returning only {"bzr-digest":"[email protected]"}

This is not just a simple ingestion task, as this needs also to work when /archive API endpoint is used (with publish commands).

Another possible solution would be to just change the behaviour of diagram.svg and return complete svg (without linked icon.svg for charms). Which sounds like a better and more browser compliant solution anyway.

The readme and icon should always be available under meta endpoints, as they were under the old charmstore. The icon should return either the icon.svg file from the charm or a default icon (we have separate default icons for every category, and one for uncategorized charms), and the readme should return either the readme text or an empty string. This will reduce our calls per details request to 1. Low priority.

Get /meta/stats on the latest revision, then use expand-id to get other revisions and check again with some past revision. /meta/stats should still show same download counts, not 0.

Search results right now are returning the ids in what appears to be a url encoded form, e.g. [{"Id":"cs%3A~lazypower%2Fprecise%2Fairtime-0"}]. I would expect them to be in the same form as other endpoints, e.g. [{"Id":"cs:~lazypower/precise/Fairtime-0"}].

When you POST an archive that is already known about the response is sent before the request has been fully received. this seems to upset apache when it is being used a proxy.

We can't use the /charm/archive/icon.svg path inside img tags as we can from the charmworld API; the svg does not load, and is identified as being in the broken state.

The mime-type is being correctly set (svg+xml); given inspection of the headers from the charmstore and charmworld, it's likely something to do with access controls, but I'm not certain.

charmworld:

{'content-length': '2718', 'via': '1.0 localhost (squid/3.1.19)', 'x-cache': 'MISS from localhost', 'content-encoding': 'gzip', 'x-cache-lookup': 'HIT from localhost:3128', 'vary': 'Accept-Encoding', 'server': 'gunicorn/0.17.2', 'etag': '"339d47da84323f27be49415223f17b1b"', 'cache-control': 'max-age=86400, public', 'date': 'Wed, 15 Oct 2014 01:04:04 GMT', 'access-control-allow-origin': '*', 'access-control-allow-headers': 'X-Requested-With', 'content-type': 'image/svg+xml'}

charmstore:

{'date': 'Wed, 15 Oct 2014 01:11:39 GMT', 'content-length': '10701', 'content-type': 'image/svg+xml'}

http get https://api.jujucharms.com/v4/~charmers/trusty/mellanox-0/meta/extra-info

vs

http get https://api.jujucharms.com/v4/trusty/mellanox-0/meta/extra-info
http get https://api.jujucharms.com/v4/trusty/mellanox-1/meta/extra-info

The wrong revision of promulgated charm happened on all testing machines as well.

Since I've narrowed it down to /trusty/juju-gui I had expected it to only show me ids for the trusty version of the charm.

I'd expect the current list for https://api.jujucharms.com/v4/juju-gui/expand-id

vivid
win2012hvr2

Will investigate to find out what others to expect.

The charmstore might be fine but limited on the charmworld side since it checks if it exists during ingestion. I'll file a matching bug on the charmworld side.

We need a one paragraph summary for users to help distinguish bundles without processing the full readme.