This repository has been archived by the owner. It is now read-only.
Permalink
Browse files

quilt: Rename the project

We've settled on Quilt as the name of the project going forward.  This
patch represents a best-effort attempt at renaming everything.
There's likely things we've missed.
  • Loading branch information...
ejj committed May 17, 2016
1 parent e031379 commit 7a625e4650f02c174f0198629741ab314a6e5266
Showing with 483 additions and 397 deletions.
  1. +1 −1 .gitignore
  2. +2 −2 Dockerfile
  3. +1 −1 Godeps/Godeps.json
  4. +1 −1 LICENSE.md
  5. +20 −19 Language.md
  6. +9 −10 Makefile
  7. +72 −25 README.md
  8. +3 −3 cluster/cluster.go
  9. +3 −3 cluster/cluster_test.go
  10. +2 −2 cluster/foreman.go
  11. +2 −2 cluster/foreman_test.go
  12. +9 −9 config_test.go
  13. +1 −1 db/cluster.go
  14. +1 −1 db/constants.go
  15. +1 −1 db/container.go
  16. +1 −1 db/etcd.go
  17. +1 −1 db/machine.go
  18. +1 −1 db/placement.go
  19. +73 −34 dev.md
  20. +1 −1 dev/README.md
  21. +4 −4 dev/Vagrantfile
  22. +0 −18 di-tester/config/hooks/pre-push
  23. +2 −2 dsl/dsl_test.go
  24. +1 −1 dsl/func.go
  25. +1 −1 dsl/imports.go
  26. +7 −7 engine/engine.go
  27. +3 −3 engine/engine_test.go
  28. +3 −3 inspect/main.go
  29. +2 −2 inspect/viz.go
  30. +4 −4 minion/docker/docker.go
  31. +2 −2 minion/elector/elector.go
  32. +4 −4 minion/engine.go
  33. +3 −3 minion/engine_test.go
  34. +8 −8 minion/main.go
  35. +9 −9 minion/network/network.go
  36. +2 −2 minion/network/network_test.go
  37. +3 −3 minion/network/store.go
  38. +2 −2 minion/network/store_test.go
  39. +45 −45 minion/network/worker.go
  40. +10 −10 minion/network/worker_test.go
  41. +4 −4 minion/scheduler/scheduler.go
  42. +3 −3 minion/scheduler/swarm.go
  43. +5 −5 minion/scheduler/swarm_test.go
  44. +2 −2 minion/server.go
  45. +16 −16 minion/supervisor/supervisor.go
  46. +9 −9 minion/supervisor/supervisor_test.go
  47. +3 −3 provider/awsSpot.go
  48. +3 −3 provider/azure.go
  49. +4 −4 provider/cloud_config.go
  50. +1 −1 provider/constraint.go
  51. +5 −5 provider/gce.go
  52. +2 −2 provider/provider.go
  53. +2 −1 provider/provider_test.go
  54. +2 −2 provider/vagrant.go
  55. +1 −1 provider/vagrant_api.go
  56. +2 −2 {di-tester → quilt-tester}/Dockerfile
  57. +19 −19 {di-tester → quilt-tester}/README.md
  58. +1 −1 di-tester/bin/dictl → quilt-tester/bin/quilt-ctl
  59. +3 −3 di-tester/bin/di-ssh-manager → quilt-tester/bin/quilt-ssh-manager
  60. +35 −35 di-tester/bin/di-tester → quilt-tester/bin/quilt-tester
  61. 0 {di-tester → quilt-tester}/bin/update-aws-creds
  62. 0 {di-tester → quilt-tester}/config/config.spec
  63. +18 −0 quilt-tester/config/hooks/pre-push
  64. 0 {di-tester → quilt-tester}/config/id_rsa
  65. 0 {di-tester → quilt-tester}/tests/docker_test
  66. 0 {di-tester → quilt-tester}/tests/etcd_test
  67. 0 {di-tester → quilt-tester}/tests/ip_test
  68. 0 {di-tester → quilt-tester}/tests/log_test
  69. 0 {di-tester → quilt-tester}/tests/minion_log.py
  70. 0 {di-tester → quilt-tester}/vagrant/Vagrantfile
  71. +10 −11 {di-tester → quilt-tester}/vagrant/setup
  72. +7 −7 di.go → quilt.go
  73. +2 −2 readme_test.go
  74. +3 −3 scripts/build-push.sh
  75. +1 −1 util/log.go
View
@@ -23,7 +23,7 @@ _testmain.go
*.test
*.prof
-di
+quilt
*.cov.html
*.cov.out
View
@@ -2,5 +2,5 @@ From alpine:3.3
Maintainer Ethan J. Jackson
RUN apk add --no-cache ca-certificates
-Copy ./di /bin/di
-Entrypoint ["di"]
+Copy ./quilt /bin/quilt
+Entrypoint ["quilt"]
View

Some generated files are not rendered by default. Learn more.

Oops, something went wrong.
View
@@ -1,4 +1,4 @@
-Copyright (c) 2015 The Declarative Infrastructure Authors
+Copyright (c) 2015 The Quilt Authors
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
View
@@ -1,5 +1,5 @@
-Policy Language Design
-======================
+Stitch -- The Quilt Language Design
+===================================
Designing languages is hard, so it's a good idea to get started early.
This is a living proposal for the policy language. It may or may not reflect
the actual implementation at any given point in time.
@@ -40,7 +40,7 @@ directly implemented in the dataplane. Administrators for example:
(user github melvinw) # Github user melvinw
```
-As DI supports more functionality, atoms will naturally expand to implement
+As stitch supports more functionality, atoms will naturally expand to implement
more concepts.
### SSH Keys
@@ -109,8 +109,9 @@ Lambdas can be given names by combining them with a `define`:
`(define Add2 (lambda (x) (+ x 2)))`
#### Evaluation
-Both built-ins and lambda functions are evaluted in the same way. The first item in the S-expression
-refers to the function to be invoked, and the remaining items are the arguments.
+Both built-ins and lambda functions are evaluated in the same way. The first
+item in the S-expression refers to the function to be invoked, and the
+remaining items are the arguments.
```
(+ 2 2) // => 4
@@ -126,9 +127,9 @@ refers to the function to be invoked, and the remaining items are the arguments.
```
## Modules
-`module` is a way of creating a namespace. It evalutes its body, and then makes
-exportable binds and labels available as `<module_name>.ident`.
-Only binds and labels that start with a capital letter are exported.
+`module` is a way of creating a namespace. It evaluates its body, and then
+makes exportable binds and labels available as `<module_name>.ident`. Only
+binds and labels that start with a capital letter are exported.
```
(module "math" (define Square (lambda (x) (* x x))))
(math.Square 5) // => 25
@@ -148,16 +149,16 @@ body is the contents of the body.
(math.Square 5) // => 25
```
-### DI_PATH
-`di` looks for imports according to the `DI_PATH` environment variable.
+### QUILT_PATH
+`quilt` looks for imports according to the `QUILT_PATH` environment variable.
So if you have a spec that imports `stdlib`, and `stdlib.spec` is located at
-`specs/stdlib.spec`, then your `DI_PATH` should be `DI_PATH="specs"`.
+`specs/stdlib.spec`, then your `QUILT_PATH` should be `QUILT_PATH="specs"`.
-Multiple paths are separated by colons, so you may do `DI_PATH="specs:specs/spark"`.
+Multiple paths are separated by colons, so you may do `QUILT_PATH="specs:specs/spark"`.
-You can invoke `di` with the path in one line:
+You can invoke `quilt` with the path in one line:
```
-DI_PATH="specs" ./di -c config.spec
+QUILT_PATH="specs" ./quilt -c config.spec
```
or `export` it into your environment.
@@ -195,7 +196,7 @@ The same labelling construction will be used for authentication policy as well.
(label admin (list grad undergrad))
```
-As DI supports more use cases, the same labeling system will apply naturally.
+As Stitch supports more use cases, the same labeling system will apply naturally.
##### Open Questions
* How do overlapping labels work? Seems like labels should be lexically scoped
@@ -224,7 +225,7 @@ The labels used in the **connect** keyword have real meaning in the
application dataplane. The *to* label will be made available to the *from*
atoms as a hostname on which sockets can be opened. In the above
example the containers implementing *webTier* may open a socket to the
-hostname "database.di" which will connect them to the appropriate database
+hostname "database.q" which will connect them to the appropriate database
containers.
##### Load Balancing
@@ -234,9 +235,9 @@ However, for connections to multiple atoms, the dataplane will automatically
load balance new connections across all available atoms.
##### Firewalling
-By default, atoms in DI cannot communicate with each other due to an implicit
-"deny all" firewall. Communication between atoms must be explicitly permitted
-by the **connect** keyword.
+By default, atoms in Stitch cannot communicate with each other due to an
+implicit "deny all" firewall. Communication between atoms must be explicitly
+permitted by the **connect** keyword.
## Placement
```
View
@@ -1,7 +1,7 @@
export GO15VENDOREXPERIMENT=1
PACKAGES=$(shell GO15VENDOREXPERIMENT=1 go list ./... | grep -v vendor)
NOVENDOR=$(shell find . -path ./vendor -prune -o -name '*.go' -print)
-REPO = quay.io/netsys
+REPO = quilt
DOCKER = docker
all:
@@ -40,28 +40,27 @@ coverage: db.cov dsl.cov engine.cov cluster.cov join.cov minion/supervisor.cov m
rm $@.out
# BUILD
-
-docker-build-di:
+docker-build-quilt:
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build .
- ${DOCKER} build -t ${REPO}/di .
+ ${DOCKER} build -t ${REPO}/quilt .
docker-build-tester:
- cd -P di-tester && ${DOCKER} build -t ${REPO}/di-tester .
+ cd -P quilt-tester && ${DOCKER} build -t ${REPO}/tester .
docker-build-minion:
cd -P minion && CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build . \
- && ${DOCKER} build -t ${REPO}/di-minion .
+ && ${DOCKER} build -t ${REPO}/minion .
# PUSH
-docker-push-di:
- ${DOCKER} push ${REPO}/di
+docker-push-quilt:
+ ${DOCKER} push ${REPO}/quilt
docker-push-tester:
- ${DOCKER} push ${REPO}/di-tester
+ ${DOCKER} push ${REPO}/tester
docker-push-minion:
- ${DOCKER} push ${REPO}/di-minion
+ ${DOCKER} push ${REPO}/minion
# Include all .mk files so you can have your own local configurations
include $(wildcard *.mk)
View
@@ -1,34 +1,81 @@
-[![Build Status](https://travis-ci.com/NetSys/di.svg?token=QspQsur4HQKsDUg6Hynm&branch=master)](https://travis-ci.com/NetSys/di)
-[![Docker Repository on Quay](https://quay.io/repository/netsys/di/status?token=9793d07b-1924-469c-b23e-ef1aa0f14e7d "Docker Repository on Quay")](https://quay.io/repository/netsys/di)
-# DI
-
-DI is a simple, declarative language to configure, boot and connect containers within your local infrastructure and across public clouds. DI enables you to create a complex distributed system of containers by working only with a simplified abstract view of your system and not worrying about the low-level implementation.
-
-If you have ever managed a distributed system, you know that as the system grows, it becomes increasingly difficult to build, configure, and maintain. For a distributed system to function well, it needs consistency among its individual components, as well as flexible and reliable composition to combine its individual components into a whole. Additionally, the system requires comprehensive configuration to control things like data flow, placement and access control.
-
-Ensuring all of the above requirements is difficult, and in recognition of this fact, several companies and open source projects have made good contributions towards simpler system administration. However, even with these tools at hand, it still requires carefully executed API calls and detailed understanding of a system's underlying infrastructure to sucessfully build and maintain it.
-
-With DI, you can leave these low-level details aside and instead focus on the high-level structure and configuration of your system. For instance, for a simple web deployment, we might want a database, some number of web servers connected to the public internet, and some batch processing servers connected to the web servers and the database. Even though this overall structure seems simple, the actual implementation quickly becomes complicated.
-
-DI enables you to bypass these complications and build your distributed system from the top down, maintaining only an abstract view of your infrastructure and a set of explicit policies it follows. You never have to worry about firewall configurations, server placement or other implicit security enforcements; your high-level view and explicit policies make it easy to monitor and verify the state of your system. Regardless of whether your application is hosted on a single or multiple cloud providers, DI ensures that your system is correctly booted and that it always follows your configuration.
-
-## The DI Language
-
-As described above, DI allows you to forget about low-level specifics and detailed API calls. With DI, you simply describe the desired state of your system, and DI then handles the rest. To describe your configuration, you will use two main building blocks: `atom`s and `label`s.
+[![Build Status](https://travis-ci.com/NetSys/quilt.svg?token=QspQsur4HQKsDUg6Hynm&branch=master)](https://travis-ci.com/NetSys/quilt)
+[![Docker Repository on Quay](https://quay.io/repository/netsys/quilt/status?token=9793d07b-1924-469c-b23e-ef1aa0f14e7d "Docker Repository on Quay")](https://quay.io/repository/netsys/quilt)
+# Quilt
+
+Quilt is a simple system to deploy and network containers across public
+clouds. Quilt enables one to create a complex distributed system of containers
+by working only with a simplified abstract view of your system and not worrying
+about the low-level implementation.
+
+As systems grow, they become increasingly difficult to build, configure, and
+maintain. For a distributed system to function well, it needs consistency among
+its individual components, as well as flexible and reliable composition to
+combine its individual components into a whole. Additionally, the system
+requires comprehensive configuration to control things like data flow,
+placement and access control.
+
+Ensuring all of the above requirements is difficult, and in recognition of this
+fact, several companies and open source projects have made good contributions
+towards simpler system administration. However, even with these tools at hand,
+it still requires carefully executed API calls and detailed understanding of a
+system's underlying infrastructure to sucessfully build and maintain it.
+
+With Quilt, you can leave these low-level details aside and instead focus on the
+high-level structure and configuration of your system. For instance, for a
+simple web deployment, we might want a database, some number of web servers
+connected to the public internet, and some batch processing servers connected
+to the web servers and the database. Even though this overall structure seems
+simple, the actual implementation quickly becomes complicated.
+
+Quilt enables you to bypass these complications and build your distributed system
+from the top down, maintaining only an abstract view of your infrastructure and
+a set of explicit policies it follows. You never have to worry about firewall
+configurations, server placement or other implicit security enforcements; your
+high-level view and explicit policies make it easy to monitor and verify the
+state of your system. Regardless of whether your application is hosted on a
+single or multiple cloud providers, Quilt ensures that your system is correctly
+booted and that it always follows your configuration.
+
+## Stitch -- The Quilt Language
+
+As described above, Quilt allows you to forget about low-level specifics and
+detailed API calls. With Quilt, you simply describe the desired state of your
+system, and Quilt then handles the rest. To describe your configuration, you will
+use two main building blocks: `atom`s and `label`s.
#### Atoms
-An `atom` is the smallest unit of the DI language. Each `atom` is either an administrative user, a public hostname or IP address, a container, or a virtual machine. Simply creating an atom in your DI config file is enough to boot and register the entity in your system. Similarly, if you want to shut down or unregister a component of your system, you just remove the corresponding atom in your config file.
-
-By default, `atom`s in DI cannot communicate with each other due to an implicit "deny all" firewall. Communication between `atom`s must therefore be explicitly permitted by the `connect` keyword. This setup makes it easy to monitor and manage data access in your system.
+An `atom` is the smallest unit of the Quilt language. Each `atom` is either an
+administrative user, a public hostname or IP address, a container, or a virtual
+machine. Simply creating an atom in your Quilt config file is enough to boot and
+register the entity in your system. Similarly, if you want to shut down or
+unregister a component of your system, you just remove the corresponding atom
+in your config file.
+
+By default, `atom`s in Quilt cannot communicate with each other due to an implicit
+"deny all" firewall. Communication between `atom`s must therefore be explicitly
+permitted by the `connect` keyword. This setup makes it easy to monitor and
+manage data access in your system.
#### Labels
-`label`s are logical groups of `atom`s and/or other `label`s. With `label`s you can create named logical units within your system that you can then connect and manage. For instance, after allowing connections from `label1` to `label2`, any container in `label1` can connect to `atom`s in `label2` by opening a socket to the hostname `label2.di`. If multiple atoms implement `label2`, DI will automatically load balance new connections across all available `atom`s.
+`label`s are logical groups of `atom`s and/or other `label`s. With `label`s you
+can create named logical units within your system that you can then connect and
+manage. For instance, after allowing connections from `label1` to `label2`, any
+container in `label1` can connect to `atom`s in `label2` by opening a socket to
+the hostname `label2.q`. If multiple atoms implement `label2`, Quilt will
+automatically load balance new connections across all available `atom`s.
## Building a simple system
-Before you start DI, you must specify the structure and requirements for your distributed system in the config file. This file is written in the declarative DI domain-specific language (`dsl`) that allows you to describe your system in an clear and abstract manner. You might for instance specify the cloud provider(s), the number of VMs, how many containers you want, what kind of containers, logical groups (`label`s), as well as connections between `label`s and/or the public internet.
+Before you start Quilt, you must specify the structure and requirements for
+your distributed system in the config file. This file is written in the
+declarative Quilt domain-specific language (`dsl`) that allows you to describe
+your system in an clear and abstract manner. You might for instance specify the
+cloud provider(s), the number of VMs, how many containers you want, what kind
+of containers, logical groups (`label`s), as well as connections between
+`label`s and/or the public internet.
-As an example, to boot 3 docker containers with the latest Ubuntu image and a postgres database, you put the following commands in your config file.
+As an example, to boot 3 docker containers with the latest Ubuntu image and a
+postgres database, you put the following commands in your config file.
<!-- BEGIN CODE -->
(label "containers" (makeList 3 (docker "ubuntu")))
@@ -68,7 +115,7 @@ After the above commands, our network looks a lot more interesting:
<img src="./doc-images/quiltAbstractWebTierConnect.png">
-With the config file in place, DI will now boot your system. If you modify the configuration after the system booted, DI will make the corresponding changes to your system in the least distruptive way possible.
+With the config file in place, Quilt will now boot your system. If you modify the configuration after the system booted, Quilt will make the corresponding changes to your system in the least distruptive way possible.
## Contributing
-If you are interested in contributing to DI, check out [dev.md](dev.md) for development instructions, details about the code structure, and more.
+If you are interested in contributing to Quilt, check out [dev.md](dev.md) for development instructions, details about the code structure, and more.
View
@@ -3,9 +3,9 @@ package cluster
import (
"time"
- "github.com/NetSys/di/db"
- "github.com/NetSys/di/join"
- "github.com/NetSys/di/provider"
+ "github.com/NetSys/quilt/db"
+ "github.com/NetSys/quilt/join"
+ "github.com/NetSys/quilt/provider"
log "github.com/Sirupsen/logrus"
)
View
@@ -5,9 +5,9 @@ import (
"testing"
"time"
- "github.com/NetSys/di/db"
- "github.com/NetSys/di/dsl"
- "github.com/NetSys/di/provider"
+ "github.com/NetSys/quilt/db"
+ "github.com/NetSys/quilt/dsl"
+ "github.com/NetSys/quilt/provider"
"github.com/davecgh/go-spew/spew"
)
View
@@ -10,8 +10,8 @@ import (
"golang.org/x/net/context"
- "github.com/NetSys/di/db"
- "github.com/NetSys/di/minion/pb"
+ "github.com/NetSys/quilt/db"
+ "github.com/NetSys/quilt/minion/pb"
log "github.com/Sirupsen/logrus"
)
View
@@ -3,8 +3,8 @@ package cluster
import (
"testing"
- "github.com/NetSys/di/db"
- "github.com/NetSys/di/minion/pb"
+ "github.com/NetSys/quilt/db"
+ "github.com/NetSys/quilt/minion/pb"
"github.com/davecgh/go-spew/spew"
)
View
@@ -5,21 +5,21 @@ import (
"testing"
"text/scanner"
- "github.com/NetSys/di/db"
- "github.com/NetSys/di/dsl"
- "github.com/NetSys/di/engine"
- "github.com/NetSys/di/util"
+ "github.com/NetSys/quilt/db"
+ "github.com/NetSys/quilt/dsl"
+ "github.com/NetSys/quilt/engine"
+ "github.com/NetSys/quilt/util"
)
-func configRunOnce(configPath string, diPath []string) error {
+func configRunOnce(configPath string, quiltPath []string) error {
f, err := util.Open(configPath)
if err != nil {
return err
}
defer f.Close()
var sc scanner.Scanner
- spec, err := dsl.New(*sc.Init(bufio.NewReader(f)), diPath)
+ spec, err := dsl.New(*sc.Init(bufio.NewReader(f)), quiltPath)
if err != nil {
return err
}
@@ -33,13 +33,13 @@ func configRunOnce(configPath string, diPath []string) error {
}
func TestConfigs(t *testing.T) {
- testConfig := func(configPath string, diPath []string) {
- if err := configRunOnce(configPath, diPath); err != nil {
+ testConfig := func(configPath string, quiltPath []string) {
+ if err := configRunOnce(configPath, quiltPath); err != nil {
t.Errorf("%s failed validation: %s", configPath, err.Error())
}
}
testConfig("./config.spec", []string{"specs/stdlib"})
- testConfig("di-tester/config/config.spec", []string{"specs/stdlib"})
+ testConfig("quilt-tester/config/config.spec", []string{"specs/stdlib"})
testConfig("specs/spark/main.spec",
[]string{"specs/stdlib", "specs/spark", "specs/zookeeper"})
testConfig("specs/wordpress/main.spec",
View
@@ -3,7 +3,7 @@ package db
import (
"fmt"
- "github.com/NetSys/di/util"
+ "github.com/NetSys/quilt/util"
)
// A Cluster is a group of Machines which can operate containers.
View
@@ -4,7 +4,7 @@ package db
import (
"errors"
- "github.com/NetSys/di/minion/pb"
+ "github.com/NetSys/quilt/minion/pb"
)
// The Role a machine may take on within the cluster.
Oops, something went wrong.

0 comments on commit 7a625e4

Please sign in to comment.