deis / deis Goto Github PK
View Code? Open in Web Editor NEWDeis v1, the CoreOS and Docker PaaS: Your PaaS. Your Rules.
Home Page: https://deis.com/docs/
License: MIT License
Deis v1, the CoreOS and Docker PaaS: Your PaaS. Your Rules.
Home Page: https://deis.com/docs/
License: MIT License
As of now only the user who created the Formation
can use the API to operate on it. This includes listing the formation, scaling it, git push
'ing to it, etc. We need a way to share those permissions with some granular access controls.
Django Rest Framework is using pagination to restrict results to 10. This makes for strange behavior like:
$ deis containers:scale web=12
$ deis containers
=== web: `gunicorn -b 0.0.0.0:$PORT app:app`
web.1 up 2013-07-27T20:37:57.994Z
web.2 up 2013-07-27T21:54:53.238Z
web.3 up 2013-07-27T21:58:06.082Z
web.4 up 2013-07-27T21:58:06.095Z
web.5 up 2013-07-27T22:02:57.508Z
web.6 up 2013-07-27T22:02:57.525Z
web.7 up 2013-07-27T22:02:57.540Z
web.8 up 2013-07-27T22:02:57.555Z
web.9 up 2013-07-27T22:02:57.572Z
web.10 up 2013-07-27T22:02:57.590Z
This is clearly a bug, but putting it off for now. There's probably a flag we can pass to the HTTP request to prevent this.
We need to provide users with some feedback during long running CLI commands like scaling nodes.
We should explore whether or not a Travis CI integration makes sense.
The logic around handling a git push
needs some love.
The API should allow users to delete an individual node by its ID. Deis provisioned the node, so in the event it started misbehaving, we shouldn't force users to go to the cloud provider to kill it.
We've seen some issues with Buildstep-included Buildpacks.
config_vars
on release (e.g. PATH, GEM_PATH)In order to facilitate fast deployment of controllers and nodes, we need to provide pre-built AMIs that include time-consuming components. AMIs will be based on stock Ubuntu 12.04 LTS and include:
We must provide the script used for bundling to provide complete transparency and allow others to recreate the bundles themselves.
Each node needs to send its logs to the controller to facilitate a deis logs
CLI command, that provides real-time log tailing across the formation.
It looks like we have an issue with Crate.io's widget. It's coming up "unknown" even though the coverage figures are there.
Before the open source release we should reset south migrations.
Formations need a way to expose HTTPS and raw SSL sockets.
Formation.rotate
should allow cycling of nodes and containers. Rotating containers by 2 would cause 2 new containers to be created followed by the 2 oldest containers being removed. Later this infrastructure can be used to implement rolling, zero-downtime deploys.
The dream of using a stripped down runtime image on execution nodes has experienced a setback. When running a Buildpack app on a stock Ubuntu image, I'm playing whack-a-dependency with system libraries -- and losing badly.
For now we'll have to exec the containers on the same image they were built with. This means bundling the Buildstep image in the optimized AMI and making it part of the Chef recipe.
Mostly so we can use ``./manage.py test client" and have a single test harness. This may involve renaming its deis package and/or moving its contents up one level.
Right now config:set
only takes one value at a time. New config values cause a new Release
to be rolled, which results in a converge of the Formation
. When updating multiple config values, this can take a painfully long time.
We need config update to take multiple values at once, so there's only a single converge.
We need a first round of docstrings for Sphinx. This is also a good chance to do some basic code cleanup and reformatting.
We need a workflow for publishing auto-generated Sphinx docs to the <deis.io> website. We can start with something manual and automate it over time.
The controller currently supports HTTP and HTTPS cluster-wide by installing an SSL cert on the load balancer fronting Deis. We need to provide a way of distributing SSL keys to the router for applications.
Right now the Django SECRET_KEY
is a hardcoded attribute. We should allow it to be set via attribute, but default to a null attribute which auto-gens a unique key during provisioning.
Besides the "quick start" documentation, we need a more comprehensive tutorial on how to use Deis once the controller is up and running.
I'm envisioning a walkthrough that describes using the CLI to deploy and manage real-world formations, while explaining key concepts and providing a deeper look at the CLI.
Maybe something similar to:
https://docs.djangoproject.com/en/dev/intro/tutorial01/
A provisioned Deis controller has permission to bootstrap new systems, creating their Node
and Client
records on the Chef Server. However after the controller terminates the systems, it's not allowed to delete the Node
and Client
records it created through the bootstrap. The API calls result in a 403 error and therefore an error during Formation.destroy()
.
The workaround for now is to place the controller node in the Chef Server's admin
group. However, there must be a more granular way grant permission to delete Node
and Client
records for objects that were bootstrapped by the controller. Looking for a better solution...
Right now artifacts are not being cached using the Buildstep integration. If the deploy pull a lot of dependencies, it can be terribly slow. This should be achieved fairly easily using bind mounts to a cache
directory in the bare git repo.
Containers need to run as a non-root user for LXC best practice.
Deis administrators need the ability to pick their release and have control over rolling out new Deis features. The current plan for this is to have the Deis admins swap the Deis cookbook version in Chef land. This should cause Deis to pull updated tags.
New users should have Providers and Flavors pre-seeded with sensible defaults. When using the CLI to provide credentials, the API will simply update the default Provider records with the credentials. Users will still be able to add/manage additional sets of credentials.
We need to complete the supported CLI features and generally cleanup the code to handle contributions.
Need to run foodcritic and update accordingly.
We should have Foodcritic, ChefSpec and MiniTest (or equivalents) running through Travis CI. We'll need to spend some time designing and writing the tests.
Right now we're using master by default, we should be using standard release tags.
SSH keys are currently attached to the Flavor
object. We need to move that to the Formation
for security.
We need code coverage reports on Buildbot.
When pushing to Heroku, an initial web
container is created automatically. This gives you a chance to test out your application without having to scale processes, making for a more streamlined initial workflow.
We need to add that same optimization to Build.push
.
Need to write a client.rst
that wraps the methods and their docstrings in a way that produces a command-line client reference. We can add the cheat sheet at the top.
Need to deprecate unused models and take another pass at cleaning up any DB schema issues.
A formation's nodes need to be running IPTables and include other system hardening tactics for Ubuntu servers. This will be implemented via Chef recipes.
We need to update the main project README to include Getting Started code snippets, links out to documentation and other basic information.
We need to re-enable Django admin and configure it correctly according to the new model design.
We need the Sphinx docs styled appropriately for the <deis.io> website.
Formations should be composed of layers, which host nodes of the same type and configuration. Layers (and their nodes) can be scaled up and down independently.
We need to do a proper URL join to make sure trailing slashes aren't relevant.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.