search

appsody / stacks

Appsody application stacks. This repo will be archived soon.
https://appsody.dev
Apache License 2.0
90 stars 120 forks source link

Stacks should be represented & addressable as a single entity in a docker repo #324

Open henrynash opened 5 years ago

henrynash commented 5 years ago

Today, in order to get the "full appsody CLI experience", we require the use of an Appsody Repo to be hosted somewhere. This is an index + pointers to template tar files + pointer to a stack image in a docker repo. This seems overly complex, requires maintenance and provides additional things that can go wrong within an enterprise.

The direction of other communities (helm, CNAB etc.) is to have the entries themselves as single objects in docker registries, with optional indexes. This allows a 1000 flowers to bloom faster. I propose we do the same for Appsody. What this would mean is:

1) An Appsody stack image would be self contained (i.e. would have the stack.yaml and templates within it). See some tangential, but relevant, work carried out by @ebullient (https://github.com/appsody/stacks/pull/300). This could then be pushed to any docker registry. 2) The Appsody CLI could operate on the such images directly and provide the same experience as today (from the user perspective) 3) We could provide similar repo classifications (stable/incubator/experimental) by having individual repos within a docker registry (e.g. appsody-stable, appsody-incubator etc.) 4) We could chose to support both a "hub/index" and a "repo" context in the Appsody CLI to allow for optional indexes (see https://github.com/appsody/stacks/issues/265 for a separate discussion on why this is somewhat broken today). Such optional index/hub support would be part of Kabanero Entries and how we provide a more integrated experience for IDEs.

ebullient commented 5 years ago

Reference also #181

neeraj-laad commented 5 years ago

I like points 1 and 2 and the general idea if not having to maintain separate images, indexes, templates etc.

I think we need to think through how other related/dependent project will be affected by this. For Example: Codewind today uses index.json files hosted on our GitHub releases to work with appsody. and Kabanero will bundles other assets like pipelines etc in the same way as we do.

henrynash commented 5 years ago

@neeraj-laad Agree entirely...this is where we have to think about the impact, and how would these projects work. Conceptually I see such indexes as optional (and useful) for certain integrations/bundling....but should not be an attribute of basic appsody operation. I consider the index.json used by Codewind as a "service" which today is a file updated directly by a release process, but could equally well be automatically updated when triggered by changes to some image repo, or even not be a file at all (with changes to codewind).

neeraj-laad commented 5 years ago

https://github.com/appsody/appsody/issues/188 has a discussion related to this issue as well. Closing that issue and we can discuss and refine the approach on this issue.

When we have a clear way fwd, we can reopen issues for all impacted components.