README
¶
NodeUp Tasks
Within a model, we recognize a few well-known task names:
- files
- packages
- services
- options
When a directory is found with one of these well-known names, the items in the subtree build tasks of the corresponding types.
(TODO: Should we just prefer extensions everywhere?)
Directories which start with an underscore are tags: we only descend into those directories if the relevant tag is present.
All other directory names can be used for organization.
Alongside each task file, a file with the same name with a .meta extension will be recognized as well. It contains additional JSON options to parameterize the task. This is useful for files or templates, which otherwise have no place to put metadata.
files
The contents of the filesystem tree will be created, mirroring what exists under the files directory.
Directories will be created as needed. Created directories will be set to mode 0755.
Files will be created 0644 (change with meta 'fileMode')
Owner & group will be root:root
Two special extensions are recognized:
- .asset will be sourced from assets. Assets are binaries that are made available to the installer, e.g. from a .tar.gz distributino
- .template is a go template
packages
Any files found will be considered packages.
The name of the file will be the package to be installed.
services
Any files found will be considered services.
The name of the file will be the service to be managed.
By default, the service will be restarted and set to auto-start on boot.
Order of operations
Logically, all operations are collected before any are performed, according to the tags.
Then operations are performed in the following order:
options packages files sysctls services
Ties are broken as follows
- A task that required more tags is run after a task that required fewer tags
- Sorted by name
- Custom packages (install a deb) are run after OS provided packages
Documentation
¶
Index ¶
Constants ¶
const DefaultProtokubeImage = "kope/protokube:1.4"
const MaxAttemptsWithNoProgress = 100
We should probably retry for a long time - there is not really any great fallback
const TagMaster = "_kubernetes_master"
Variables ¶
This section is empty.
Functions ¶
func FindOSTags ¶
func FindOSTags(rootfs string) ([]string, error)
FindOSTags infers tags from the current distro We will likely remove this when everything is containerized
Types ¶
type Image ¶
type Image struct {
// Source is the URL from which we should download the image
Source string `json:"source,omitempty"`
// Hash is the hash of the file, to verify image integrity (even over http)
Hash string `json:"hash,omitempty"`
}
Image is a docker image we should pre-load
type Loader ¶
type Loader struct {
TemplateFunctions template.FuncMap
// contains filtered or unexported fields
}
type NodeUpCommand ¶
type NodeUpCommand struct {
ConfigLocation string
ModelDir vfs.Path
CacheDir string
Target string
FSRoot string
// contains filtered or unexported fields
}
type NodeUpConfig ¶
type NodeUpConfig struct {
// Tags enable/disable chunks of the model
Tags []string `json:",omitempty"`
// Assets are locations where we can find files to be installed
// TODO: Remove once everything is in containers?
Assets []string `json:",omitempty"`
// Images are a list of images we should preload
Images []*Image `json:"images,omitempty"`
// ConfigBase is the base VFS path for config objects
ConfigBase *string `json:",omitempty"`
// ClusterLocation is the VFS path to the cluster spec
// Deprecated: prefer ConfigBase
ClusterLocation *string `json:",omitempty"`
// InstanceGroupName is the name of the instance group
InstanceGroupName string `json:",omitempty"`
// ClusterName is the name of the cluster
// Technically this is redundant - it is in ClusterLocation, but this can serve as a cross-check,
// and it allows us to more easily identify the cluster, for example when we are deleting resources.
ClusterName string `json:",omitempty"`
// ProtokubeImage is the docker image to load for protokube (bootstrapping)
ProtokubeImage *Image `json:"protokubeImage,omitempty"`
// Channels is a list of channels that we should apply
Channels []string `json:"channels,omitempty"`
}
type ProtokubeFlags ¶
type ProtokubeFlags struct {
DNSZoneName *string `json:"dnsZoneName,omitempty" flag:"dns-zone-name"`
Master *bool `json:"master,omitempty" flag:"master"`
Containerized *bool `json:"containerized,omitempty" flag:"containerized"`
LogLevel *int `json:"logLevel,omitempty" flag:"v"`
Channels []string `json:"channels,omitempty" flag:"channels"`
}
type TaskBuilder ¶
type TaskBuilder func(name string, contents string, meta string) (fi.Task, error)