This may seem like a small detail but what License is the project under? In UI package.json I see MIT. But, aren't most k8s based projects Apache? Since there is no license file I wasn't sure the intent. So, I don't know what I'm consuming nor what I might contribute under.

We initially spec'd out the MVP to include non-version-specific chart responses for the following routes:

• /{:apiVersion}/charts (get all repo+charts)
• /{:apiVersion}/charts/{:repo} (get all charts that are included in {:repo})

Currently the API returns comprehensive, chart+version lists for those routes, which won't fulfill every client use-case. We should consider stripping the version data from the above collection API endpoints on behalf of the client.

Currently, the UI has the backend domain and port hardcoded. We must find a way to set those values via env variables.

In theory this is feasible using webpack but last time I looked into it I could not find a simple solution since angular-ui bundles its own webpack configuration and did not allow extending it.

Additionally, it works inconsistently. The "latest" link should really only appear on the following route endpoint:

• /{:apiVersion}/charts/{:repoName}/{:chartName}

It doesn't make sense to have a "latest" link on the following endpoints:

• /{:apiVersion}/charts
• /{:apiVersion}/charts/{:repoName}
• /{:apiVersion}/charts/{:repoName}/{:chartName}/versions
• /{:apiVersion}/charts/{:repoName}/{:chartName}/versions/{:chartVersion}

It should have full support for the SPA actions, including search

We're currently relying on a black box implementation inside the data.Charts.Refresh method. For the data.cache.cachedCharts implementation of data.Charts specifically, we have an http.Get implementation that operates against the URLs in the knownRepos instance slice map.

Less specifically, what we want is to be able to pass an interface into Refresh so that we can provide a fetcher implementation that is backed by mock data, for tests. Until then we're relying on actual HTTP connections to the prod repos to test data.cache.

Apparently based on my tests http://localhost:8080/v1/charts/stable/redmine and http://localhost:8080/v1/charts/stable/redmine/versions return both the same result and the same kind of object (chart).

Is this a desired behavior? Maybe for the /stable/redmine/versions API endpoint, we should change the type to chartVersion, and for the /stable/redmine case, remove the version specific attributes as suggested here #29.

What's your take on this?

Currently the API returns mocked chart data, we should change this behaviour to fetch from real repos.

There should be a configuration file that lists the Chart repositories to fetch from, by default it will point to the stable and incubator repositories (http://storage.googleapis.com/kubernetes-charts and http://storage.googleapis.com/kubernetes-charts-incubator)

Recently, we have an error in the UI #63.

Some of the npm packages are outdated. This is causing errors when I introduce new components or a new version of angular/material2 package. Also, current angular-cli version uses a webpack beta version. The latest version of webpack is a RC and this package is an important dependency.

Currently, the client uses a mocked version (src/ui/src/assets/mock_readme.md) of a Readme file in all the charts, we must change this to use the ChartVersion specific Readme content exposed via the monocular API.

Note: This issue is blocked until this other issue is solved.

"urls" array should not be present in the following API endpoints:

• /{:apiVersion}/charts
• /{:apiVersion}/charts/{:repoName}
• /{:apiVersion}/charts/{:repoName}/{:chartName}/versions

We only want to get a link to the full chart for the version-specific endpoint:

• /{:apiVersion}/charts/{:repoName}/{:chartName}/versions/{:chartVersion}

This header is only present in the home page. It should be present in all the pages.

It should also add a search bar in the header (how initially was) for pages that are not the home page.

Currently the charts implementation is hard-coded inside swagger/restapi/configure_monocular.go. We should instead:

1. Define a configuration spec that all instances of the running server (prod, dev, test) can consume.
2. Implement a "prod" config spec that delivers a charts implementation backed by real production repo data.
3. Implement a "test" config spec that delivers a charts implementation backed by mock data.

Implement a SEO friendly rendering of the current Angular SPA.

We can do this implementing server side rendering or any other cache mechanism.

The client has a deficient test coverage, we should at least have good testing for:

• Search engine
• Data services
• Chart#show components

• In the sidebar, have a list of versions similar to:
  

• Ideally, these versions should link to an specific version of the chart that loads an specific version of the readme.

Blocked by #32

• For simplicity, accept a single param (query) that search across multiple fields
• Include keywords in search (a search for database should bring up MySQL, MariaDB, PostgreSQL, etc.)
• Search descriptions and READMEs
• Full text search implementation across READMEs and descriptions

Currently, the chart payload sends the attribute repo = x (i.e stable).

In the UI, we need to create proper instructions on how to add a custom repository and in order to do so ideally we should be able to get the URL from the payload itself.

I'd add repoURL to the chart Payload.

Refs #80

The search results layout needs to be adapted to the new UI framework.

cc/ @Angelmmiguel

When we are retrieving data from the API, we must display a loading animation.

I'm trying to use the new API for icons. I'm using the path from the charts request but I'm getting 404 errors:

If you access for example to http://localhost:8080/v1/charts/stable/redmine you get the following output.

{
data: {
  attributes: {
    created: "2016-10-06T16:23:20.499814565-06:00",
    description: "A flexible project management web application.",
    digest: "99c76e403d752c84ead610644d4b1c2f2b453a74b921f422b9dcb8a7c8b559cd",
    home: "https://k8s.io/helm",
    name: "redmine",
    repo: "stable",
    sources: [
      "https://github.com/kubernetes/charts/redmine"
   ],
   urls: [
     "https://storage.googleapis.com/kubernetes-charts/redmine-0.0.1.tgz"
  ]
  },
  id: "stable/redmine",
  links: {
    latest: "/v1/charts/stable/redmine/0.0.1"
  },
  type: "chart"
 }
}

Latest Link

For example the latest link points to /v1/charts/stable/redmine/0.0.1 but I am wondering if it should include the /versions namespace, i.e /v1/charts/stable/redmine/versions/0.0.1

Digest

Shouldn't this route return a non-version Chart resource. If that's the case, shouldn't we remove digest and the Urls?

Recently, @migmartri updated the API to expose icons of different sizes. We have to update the frontend to get the icons from the correct attribute.

In the UI, the order of the charts seem to be defined in a random order probably generated at importation time.

We need to make it deterministic, maybe setting a default sorting by name.

This is specially a problem if we enable replication in the backend in which case we will get different order depending on the backend responding the request.

Hey,

I would like to invest with you the potential integration of https://github.com/cn-app-registry/cnr-server/
as your storage/backend api to search/push/pull chart.
Can you help me to list potential blockers for monucular to adopt it.

Some details about the cnr-project:
https://groups.google.com/forum/#!topic/kubernetes-sig-apps/R4H99dwZCQY

The latest version of the code seems to raise the following error getting stuck in the loading page.

snack-bar-container.js:4Uncaught TypeError: Cannot read property 'prototype' of undefined
    at __extends (snack-bar-container.js:4)
    at snack-bar-container.js:28
    at Object.<anonymous> (snack-bar-container.js:122)
    at __webpack_require__ (bootstrap 9464e2d…:52)
    at Object.<anonymous> (snack-bar-ref.js:70)
    at __webpack_require__ (bootstrap 9464e2d…:52)
    at Object.<anonymous> (menu.js:40)
    at __webpack_require__ (bootstrap 9464e2d…:52)
    at Object.<anonymous> (icon.js:264)
    at __webpack_require__ (bootstrap 9464e2d…:52)

I am using the bundled docker-compose file and accessing the UI via localhost:4200

It might be related to the changes introduced here #59

Some chart details pages are not displayed correctly. We need to update the flex properties to prevent this .

I have noticed that the ChartResourceAttributes in the swagger.yml does not include the icon attribute that is exposed in the repository index file (see Jenkins in this index)

We should expose this icon Url value through the non-versioned ChartProperties payload in the API.

I have suggested to populate the logos attributes in next versions of the official charts here

Currently, the search uses description and name to retrieve results. We should also take chart keywords in consideration.

It includes all available Charts. We can reuse this view for Search.

build is broken due to some incompatibility with the ng-meta library. It seems a common issue with many other libraries and angular 2 angular/angular-cli#3707

 ng build --target=production --environment=prod

ui_1   | ERROR in Error encountered resolving symbol values statically. Calling function 'MetaModule', function calls are not supported. Consider replacing the function or lambda with a reference to an exported function, resolving symbol AppModule in /app/src/app/app.module.ts, resolving symbol AppModule in /app/src/app/app.module.ts

ERROR in Error encountered resolving symbol values statically. Calling function 'MetaModule', function calls are not supported. Consider replacing the function or lambda with a reference to an exported function, resolving symbol AppModule in /app/src/app/app.module.ts, resolving symbol AppModule in /app/src/app/app.module.ts

ERROR in ./~/css-loader!./~/postcss-loader!./~/sass-loader!./src/styles.scss
Module build failed: BrowserslistError: Unknown version 55 of and_chr
    at error (/app/node_modules/browserslist/index.js:23:15)
    at Function.select (/app/node_modules/browserslist/index.js:452:21)
    at /app/node_modules/browserslist/index.js:109:38
    at Array.forEach (native)
    at browserslist (/app/node_modules/browserslist/index.js:95:16)
    at isSupported (/app/node_modules/caniuse-api/dist/index.js:66:37)
    at /app/node_modules/postcss-merge-rules/dist/lib/ensureCompatibility.js:101:66
    at /app/node_modules/postcss-selector-parser/dist/selectors/container.js:170:26
    at Selector.each (/app/node_modules/postcss-selector-parser/dist/selectors/container.js:153:22)
    at Selector.walk (/app/node_modules/postcss-selector-parser/dist/selectors/container.js:169:21)
    at /app/node_modules/postcss-selector-parser/dist/selectors/container.js:173:31
    at Root.each (/app/node_modules/postcss-selector-parser/dist/selectors/container.js:153:22)
    at Root.walk (/app/node_modules/postcss-selector-parser/dist/selectors/container.js:169:21)
    at Processor.func (/app/node_modules/postcss-merge-rules/dist/lib/ensureCompatibility.js:80:17)
    at Processor.process (/app/node_modules/postcss-selector-parser/dist/processor.js:34:14)
    at /app/node_modules/postcss-merge-rules/dist/lib/ensureCompatibility.js:121:12
    at Array.every (native)

cc/ @prydonius @Angelmmiguel

Currently #74, the system saves chart package readme files at $HOME/repo-data, we must support a way to allow its override the location via flags or ENV vars.

That way, deployments will be simplified #34

Every hour a repository refresh happens, we need to check the correct behavior on:

During refresh:

• The previous data (or updated set) stays and is accessible.
• If refresh fails, it should not take down the current data state
• If one repository is down, it should not affect the importation of other repos

We're currently using a simple custom convenience function to compare semver strings. Let's investigate a pre-existing project that has more features. As a place to start, Helm is using github.com/Masterminds/semver.

Description

Currently, the UI uses the description for searching capabilities, which means that descriptions like Chart for MariaDB are poor.

We need to add something more descriptive and useful like:

MariaDB is a fast, reliable, scalable, and easy to use open-source relational database system. MariaDB Server is intended for mission-critical, heavy-load production systems as well as for embedding into mass-deployed software.

Icons

Most of the charts do not have icons or they are too small. We need to add those icons upstream.

State

chaoskube (stable)

• Description
• Icon

chronograf (stable)

• Description
• Icon

cockroachdb (stable)

• Description
• Icon

concourse (stable)

• Description
• Icon

datadog (stable)

• Description
• Icon

dokuwiki (stable)

• Description
• Icon

drupal (stable)

• Description
• Icon

etcd-operator (stable)

• Description
• Icon

factorio (stable)

• Description
• Icon

ghost (stable)

• Description
• Icon

gitlab-ce (stable)

• Description
• Icon

grafana (stable)

• Description
• Icon

influxdb (stable)

• Description
• Icon

jasperreports (stable)

• Description
• Icon

jenkins (stable)

• Description
• Icon

joomla (stable)

• Description
• Icon

kapacitor (stable)

• Description
• Icon

kube-lego (stable)

• Description
• Icon

kube2iam (stable)

• Description
• Icon

linkerd (stable)

• Description
• Icon

magento (stable)

• Description
• Icon

mariadb (stable)

• Description
• Icon

mediawiki (stable)

• Description
• Icon

memcached (stable)

• Description
• Icon

minecraft (stable)

• Description
• Icon

minio (stable)

• Description
• Icon

mongodb (stable)

• Description
• Icon

mysql (stable)

• Description
• Icon

nginx-lego (stable)

• Description
• Icon

odoo (stable)

• Description
• Icon

opencart (stable)

• Description
• Icon

openvpn (stable)

• Description
• Icon

orangehrm (stable)

• Description
• Icon

osclass (stable)

• Description
• Icon

owncloud (stable)

• Description
• Icon

phabricator (stable)

• Description
• Icon

phpbb (stable)

• Description
• Icon

postgresql (stable)

• Description
• Icon

prestashop (stable)

• Description
• Icon

prometheus (stable)

• Description
• Icon

rabbitmq (stable)

• Description
• Icon

redis (stable)

• Description
• Icon

redmine (stable)

• Description
• Icon

sapho (stable)

• Description
• Icon

sensu (stable)

• Description
• Icon

spark (stable)

• Description
• Icon

spartakus (stable)

• Description
• Icon

spinnaker (stable)

• Description
• Icon

sumokube (stable)

• Description
• Icon

telegraf (stable)

• Description
• Icon

testlink (stable)

• Description
• Icon

traefik (stable)

• Description
• Icon

uchiwa (stable)

• Description
• Icon

wordpress (stable)

• Description
• Icon

artifactory (incubator)

• Description
• Icon

consul (incubator)

• Description
• Icon

elasticsearch (incubator)

• Description
• Icon

etcd (incubator)

• Description
• Icon

kafka (incubator)

• Description
• Icon

kube-ops-view (incubator)

• Description
• Icon

mongodb-replicaset (incubator)

• Description
• Icon

patroni (incubator)

• Description
• Icon

tensorflow-inception (incubator)

• Description
• Icon

zookeeper (incubator)

• Description
• Icon

Readme API exposure

The UI requires the retrieval of a README file content in order to render it.

Since the Readme file content can change from version to version, its content should come in the chartVersion API call /charts/{repo}/{chartName}/versions and /charts/{repo}/{chartName}/versions/{version}

Maybe we should not add the readme file content to the listing of ChartVersions (/charts/{repo}/{chartName}/versions) in order to not overload the API call.

Readme importation

As discussed here, the Readme file for now is not going to be exposed in the index.yaml file but it is part of the tgz file, so we would need to do some "extra work" during chart versions ingestion.

Chart page.

Search page.

For example this is not valid.

 helm install incubator/consul --version 0.1.3

We might want to show how to add the incubator repo before.

@prydonius what's your take here?

Currently, the md parser in the UI does not seem to comply with Github.md.

• See if the current library has a flag to enable this format
• Otherwise install an alternative. i.e https://github.com/github/markup
  

Angular-cli uses Jasmine + Karma for unit testing and protractor for e2e (end to end) testing. This means we need a browser to run the tests, so now it's impossible to run them in the container. In addition, we must configure TravisCI to run UI tests too.

PhantomJS is a good option, but we need some time to configure it. Based on previous experiences, sometimes it's difficult to configure JS testing + phanomjs in a container.

An user opened a similar issue in angular-cli repo: angular/angular-cli#2013

Create a Helm Chart that allows the configuration of:

• Helm Chart repositories from which the backend is going to feed from (low prior)
• Backend Hostname to be used by the UI
• Common persistence and services exposure settings

It includes all the information of a Chart.

This link must redirect user to / instead of reload the entire page.

Currently, when going to an specific chart page, the client asks for all the charts (v1/charts) and iterates looking for the one it is interested in.

Now, the API exposes an API endpoint that fits better that requirement /v1/charts/:repo/:chart

• Change the chartsService to use this endpoint instead

As explained here, the Charts index contains an icon attribute which represents an iconURL.

For the initial version of Monocular, it is fine that we show the images pointed by those external links but for future versions we should think of:

At importation time:

• Get the images, process it to our desired format and aspect ratio.
• Store the resulting image in a known persistent location.

Then the Monocular backend will expose these images from the new location. This will avoid having wrong images aspect ratios and possible attacks/outages because of the image hotlink.

Check that the UI comply with the minimal basic SEO technical requirements in terms of labels, meta, content, URL's, etc.

/charts should support /charts/:repo

• Add those routes pointing to the same component
• Change SEO metadata to show ":repo charts"
• Use API endpoint to load those charts instead of client side filtering.

Currently, the logo shown in the Frontend is hardcoded, we should show the logo exposed via the backend API and fallback to a default value (maybe the one shown now) if no icon is provided.

Note: This issue is blocked by the completion of #37