duglin

1. line 1
2. line 2 1.1. line 2.1 1.1. line 2.2

test link

duglin

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

package main

/*

fakepod:

This program will monitor all of the containers running on a node and for each
one will check to see if its a Kubernetes managed one. If so, then it skips it.
If it's not managed by Kubernetes then we want to calculate the total amount
of resources used by all of these containers and create a pod which reserves

duglin

CNCF Serverless SIG Charter

Introduction

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

Discovery and Subscroption Primer - WIP

Abstract

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.

duglin

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

package main

import (
	"crypto/sha256"
	"crypto/tls"
	"encoding/json"
	"flag"
	"fmt"
	"io/ioutil"
	"net/http"

duglin

spec:
  serviceClassName: user-provided-service
  planName: default
  parameters:
  - name: username               # easy name/value pair case
    value: root
  - name: password               # pull value from a secret's key
    valueFrom:
      secretKeyRef:
        name: mySecret1

duglin

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

duglin

Table of Contents

• header
  • [nested[(#nested)

line link

section 1

section

Section

section 1

section 1