Hi,

I'm wondering whether there are plans to add meta-data to bosh release
manifest, as to support better discoverability of bosh releases.

The bosh hub is providing a great one shop place to find bosh releases,
and it would be great to have it augmented with meta-data / classification.

This meta-data could be external to the release (e.g. in bosh-hub) or
embedded in the release similar to juju charms meta-data [1] or most
package manager provide (yum, apt ...) to attach meta-data to packages.

I drafted possible meta-data / classification into [2] as to start the
discussion.

Thanks in advance,

Guillaume.

[1] https://jujucharms.com/docs/stable/authors-charm-metadata
[2] https://github.com/cloudfoundry-community/awesome-bosh-releases

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh

I am thinking we can add metadata to config/final.yml (and eventually
include it in the release tarballs in release.MF). Once config/final.yml
includes metadata, bosh.io can pull it in down and include it on release
versions pages.

I'll reply to this thread with a format for config/final.yml based on your
repo in coming days.

Thanks for kicking this off!

On Fri, Jul 10, 2015 at 2:23 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

I'm wondering whether there are plans to add meta-data to bosh release
manifest, as to support better discoverability of bosh releases.

The bosh hub is providing a great one shop place to find bosh releases,
and it would be great to have it augmented with meta-data / classification.

This meta-data could be external to the release (e.g. in bosh-hub) or
embedded in the release similar to juju charms meta-data [1] or most
package manager provide (yum, apt ...) to attach meta-data to packages.

I drafted possible meta-data / classification into [2] as to start the
discussion.

Thanks in advance,

Guillaume.

[1] https://jujucharms.com/docs/stable/authors-charm-metadata
[2] https://github.com/cloudfoundry-community/awesome-bosh-releases

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh

Another use-case for such meta-data might be for a bosh release to specify
minimum bosh and stemcell supported versions (similar to what cf-release
release notes document informally, sometimes upon user requests [1]), and
possibly have bosh director enforce these requirements.

[1]
http://cf-bosh.70367.x6.nabble.com/cf-bosh-cf-release-v214-release-notes-tp534p542.html

On Sat, Jul 18, 2015 at 11:18 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Great, thanks a lot Dmitriy, this sounds great.

Looking forward to seeing bosh.io leveraging these meta data to help
filter/sort/search releases.

Guillaume.
Le 18 juil. 2015 03:39, "Dmitriy Kalinin" <dkalinin(a)pivotal.io> a écrit :

I am thinking we can add metadata to config/final.yml (and eventually
include it in the release tarballs in release.MF). Once config/final.yml
includes metadata, bosh.io can pull it in down and include it on
release versions pages.

I'll reply to this thread with a format for config/final.yml based on
your repo in coming days.

Thanks for kicking this off!

On Fri, Jul 10, 2015 at 2:23 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

I'm wondering whether there are plans to add meta-data to bosh release
manifest, as to support better discoverability of bosh releases.

The bosh hub is providing a great one shop place to find bosh releases,
and it would be great to have it augmented with meta-data / classification.

This meta-data could be external to the release (e.g. in bosh-hub) or
embedded in the release similar to juju charms meta-data [1] or most
package manager provide (yum, apt ...) to attach meta-data to packages.

I drafted possible meta-data / classification into [2] as to start the
discussion.

Thanks in advance,

Guillaume.

[1] https://jujucharms.com/docs/stable/authors-charm-metadata
[2] https://github.com/cloudfoundry-community/awesome-bosh-releases

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh

cf-release notes do not specify a minimum version. They simply include a
soft recommendation, a known-good combination. They should not be regarded
as requirements, not something one would want a BOSH director to enforce.

I would not want to burn any particular soft recommendation into metadata
associated with a final release. A particular final release may be
compatible with many stemcells and releases, not all combinations of which
are known at final-release creation time. I'd rather have a discoverable,
queryable artifact published any time a particular (release version,
stemcell, director version, dependent-release versions) combination goes
green through the appropriate CI pipeline.

Let me expand on that last bit about publishing "green combinations".
Apologies in advance for taking the conversation in a different direction.
Nothing here precludes adding metadata to releases, but I think the big
picture problem you're trying to solve is not primarily to have releases
queryable and filterable, but some other abstraction be queryable and
filterable.

A user is typically not interested in a particular release per se, but
rather a BOSH-deployed service or set of services, composed of one or more
BOSH deployments, each of which may be composed of one or more BOSH
releases, not to mention stemcells. Currently cf-release is the most
popular BOSH repository, it's typically used as a stand-alone release, as
part of a single deployment, and the manifest generation strategies are
encapsulated in the spiff templates that are checked into the release repo.

This model does not scale well, especially as it will become more and more
common for users to deploy the Diego backend for cloud foundry, whose
development has benefited greatly by being an independent release (and
usually, a separate deployment altogether, deployed alongside cf). Diego
is one of many examples* driving out a view that what the user consumes is
usually one, but sometimes several deployments, each composed of possibly
many releases, and sometimes even more than one stemcell. Note, part of
what the user consumes are the tools and templates to generate these
deployment manifests.

What the Release Integration team is working on over the next few months
is patterns for certifying deployments. A deployment is something like the
CF platform service, and what determines a good deployment is a combination
of all the things mentioned above (templates, releases, stemcells). I can
imagine these certified deployment artifacts becoming the thing one
searches, queries, and filters on bosh.io.

* other examples include:
- Concourse is typically deployed as a single deployment composed with
garden-linux-release
- Diego wants to consume garden-linux as a separate release to avoid
having the source code copy-pasted
- We want to extract etcd-release so that it's not copy pasted between cf
and diego, and can be used a general purpose etcd release
- We want to extract an identity release (UAA) so that cf and BOSH can
both re-use it without copy-paste
- Many services want to include a loggregator release so they can colocate
the metron agent on all of their jobs for metrics reporting, but don't want
to require the whole cf-release to get metron agent, thus the desire to
extract a loggregator-release

Thanks,
Amit, CF Release Integration PM

On Mon, Aug 3, 2015 at 11:52 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Another use-case for such meta-data might be for a bosh release to
specify minimum bosh and stemcell supported versions (similar to what
cf-release release notes document informally, sometimes upon user requests
[1]), and possibly have bosh director enforce these requirements.

[1]
http://cf-bosh.70367.x6.nabble.com/cf-bosh-cf-release-v214-release-notes-tp534p542.html

On Sat, Jul 18, 2015 at 11:18 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Great, thanks a lot Dmitriy, this sounds great.

Looking forward to seeing bosh.io leveraging these meta data to help
filter/sort/search releases.

Guillaume.
Le 18 juil. 2015 03:39, "Dmitriy Kalinin" <dkalinin(a)pivotal.io> a
écrit :

I am thinking we can add metadata to config/final.yml (and eventually
include it in the release tarballs in release.MF). Once config/final.yml
includes metadata, bosh.io can pull it in down and include it on
release versions pages.

I'll reply to this thread with a format for config/final.yml based on
your repo in coming days.

Thanks for kicking this off!

On Fri, Jul 10, 2015 at 2:23 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

I'm wondering whether there are plans to add meta-data to bosh release
manifest, as to support better discoverability of bosh releases.

The bosh hub is providing a great one shop place to find bosh
releases, and it would be great to have it augmented with meta-data /
classification.

This meta-data could be external to the release (e.g. in bosh-hub) or
embedded in the release similar to juju charms meta-data [1] or most
package manager provide (yum, apt ...) to attach meta-data to packages.

I drafted possible meta-data / classification into [2] as to start the
discussion.

Thanks in advance,

Guillaume.

[1] https://jujucharms.com/docs/stable/authors-charm-metadata
[2] https://github.com/cloudfoundry-community/awesome-bosh-releases

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh

_______________________________________________
cf-bosh mailing list
cf-bosh(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-bosh