Skip to content

Instantly share code, notes, and snippets.

duglin /
Last active January 21, 2022 13:26

Current version of the spec defines epoch as:

Epoch: Description: The Discovery Endpoint's epoch value for this Service Entry. This specification does not mandate any particular semantic meaning to the value used. For example, implementations are free to use a value that represents a timestamp or could choose to simply use a monotonically increasing number. The only requirement is that the value MUST always increase each time the Service Entry is updated. This allows for a quick integer comparision to determine which version of this Service Entry is the latest - meaning, the one with the larger integer value.

duglin /
Last active June 4, 2020 19:12
Discovery and Subscription Primer - WIP

Discovery and Subscroption Primer - WIP


This non-normative document provides an overview of the Discovery and Subscription API specifications. It is meant to complement those specifications to provide additional background and insight into the history and design decisions made during their development. This allows the specification itself to focus on the normative technical details.

interface CloudEvent {
String getSubject();
ZonedDateTime getTime();
Map<String, Object> getExtensions();
Object getExtension(key);
T/Object get(key); // used for spec attrs and extensions
interface CloudEventBuilder {
duglin /
Last active November 6, 2020 07:44
Proposed SIG-Serverless Charter

CNCF Serverless SIG Charter


This is the charter referred to in “CNCF SIGs” by the CNCF TOC, and consistent with the proposed SIG definition.

Borrowing from the [Serverless

duglin /
Last active August 22, 2022 14:55
  1. line 1
  2. line 2 1.1. line 2.1 1.1. line 2.2

test link

package main
import (
duglin / params.yaml
Last active July 27, 2017 05:13
serviceClassName: user-provided-service
planName: default
- name: username # easy name/value pair case
value: root
- name: password # pull value from a secret's key
name: mySecret1
duglin / PodPreset Ramblings
Last active July 12, 2017 20:46
PodPreset Ramblings
Some aspects that influence my thinking on this:
- having PodPresets in a Binding is causing problems
- first, because we'll be constantly chasing the real PodPreset definition
- second, because we actually don't want a full PodPreset with all of its features,
we just need the bits related to Secrets
- third, PodPresets (as of now) are immutable
- we need to allow for people to specify more than one LabelSelector at a time to support
upgrading of apps
- as long as the LabelSelector is immutable and embedded in a Binding we should separate the
idea of asking for creds from linking the creds to an app to allow for changing LabelSelectors
"_id": "apsMyserviceParametersDemo_id",
"catalog": {
"bindable": true,
"name": "apsMyserviceParametersDemo",
"tags": [
"version": "",


two words



with ' punct

with . dot

with ... dots