facsimile


Namefacsimile JSON
Version 0.0.1 PyPI version JSON
download
home_pagehttps://github.com/20c/facsimile
SummaryUNKNOWN
upload_time
maintainerNone
docs_urlNone
author20C
requires_pythonNone
licenseLICENSE.txt
keywords
VCS
bugtrack_url
requirements No requirements were recorded.
Travis-CI No Travis.
coveralls test coverage No coveralls.
            Facsimile
=========

Contents
--------

.toc 0


Introduction
------------

Facsimile is designed to create exact environment copies for local development
instances and deployed staging and production environments.

It supports multiple hosts, as well as multiple geographic regions.

You can use either by making a separate repo for a conglomerate, or by putting
defintions in config/facsimile.json

Internals
---------

### Definitions

* project : highest level of facsimile config, can contain other subprojects
* modules : project wide pieces, these are used to specify any sections that might be used between subprojects, or need separate passwords, etc

* instances :
  An instance is a set of machines, acting on concert to
  produce the full experience of using the platform. Another meaning of
  instance, in the deploy sense, is the set of configurations (including extra
  directory, instance.json, passwd.json generated file, etc) that allow the
  instance to be updated using the deploy scripts.

instance data is shared across projects

* targets : instances may be broken into different node types (e.g., frontend, database, app) called targets



rename:
An instance in a daemon
  level sense refers to the fact that we sometimes run more than one copy of the
  same code, off the same binary filename - usually with different arguments.
  For now we are doing this purely for an HA/LB or sharding perspective, but we may
  add further uses as well (such as hot spares - our existing HA is load
  balanced).

* definition : defines a project down to each instance, contains no state info. Definitions can be inherited infinately to avoid redefining anything
* state : configured and generated information that is instance specific.  For example, passwords, directories


rm:
per instance specific configuration for the deployment system to set up an install.
* environment : environment specific
* subinstance : sometimes, the 1:1 nature of the instance term becomes 1:2, or
  1:3.. or 1:n. For example, iceberg: we don't want to separately maintain the
  configurations for dev4.ch1's instance, dev0.ch0's instance, and
  dev5.ch1's instance separately, and we want to keep the passwords and
uiid in sync, for clarity.  However, there are subtle differences that should
be tracked. This is like an overlay, in a way - but it's for the whole
instance (in a deploy sense), not just one of the software packages.

### Directory Layout

* SRC/
  source checkouts - not separated by instance, assumes version tags are enough
* BUILD/
  out of source build trees, subdirectoried under $instance/
* define/
  instance definition files

* extra/
  extra files to be deployed
* tmpl/
  tmpl files to be rendered and then deployed


Templates
---------

Available structures are `instance` and `module`

config file templates should be kept with the source repository as much as possible, so changes are versioned along with the code that uses them


Modules
-------

name: module name
genconfig: should facs genarate a config for this
write_sql: <remove>

db::

Class Overrides
---------------

_init_<system>



Notes
-----

if project name matches a directory in deploy, rsync --delete is used to clean up the deploy
            

Raw data

            {
    "_id": null,
    "maintainer": null,
    "docs_url": null,
    "requires_python": null,
    "maintainer_email": null,
    "cheesecake_code_kwalitee_id": null,
    "keywords": null,
    "author": "20C",
    "home_page": "https://github.com/20c/facsimile",
    "github_user": "20c",
    "download_url": "UNKNOWN",
    "platform": "UNKNOWN",
    "version": "0.0.1",
    "cheesecake_documentation_id": null,
    "description": "Facsimile\n=========\n\nContents\n--------\n\n.toc 0\n\n\nIntroduction\n------------\n\nFacsimile is designed to create exact environment copies for local development\ninstances and deployed staging and production environments.\n\nIt supports multiple hosts, as well as multiple geographic regions.\n\nYou can use either by making a separate repo for a conglomerate, or by putting\ndefintions in config/facsimile.json\n\nInternals\n---------\n\n### Definitions\n\n* project : highest level of facsimile config, can contain other subprojects\n* modules : project wide pieces, these are used to specify any sections that might be used between subprojects, or need separate passwords, etc\n\n* instances :\n  An instance is a set of machines, acting on concert to\n  produce the full experience of using the platform. Another meaning of\n  instance, in the deploy sense, is the set of configurations (including extra\n  directory, instance.json, passwd.json generated file, etc) that allow the\n  instance to be updated using the deploy scripts.\n\ninstance data is shared across projects\n\n* targets : instances may be broken into different node types (e.g., frontend, database, app) called targets\n\n\n\nrename:\nAn instance in a daemon\n  level sense refers to the fact that we sometimes run more than one copy of the\n  same code, off the same binary filename - usually with different arguments.\n  For now we are doing this purely for an HA/LB or sharding perspective, but we may\n  add further uses as well (such as hot spares - our existing HA is load\n  balanced).\n\n* definition : defines a project down to each instance, contains no state info. Definitions can be inherited infinately to avoid redefining anything\n* state : configured and generated information that is instance specific.  For example, passwords, directories\n\n\nrm:\nper instance specific configuration for the deployment system to set up an install.\n* environment : environment specific\n* subinstance : sometimes, the 1:1 nature of the instance term becomes 1:2, or\n  1:3.. or 1:n. For example, iceberg: we don't want to separately maintain the\n  configurations for dev4.ch1's instance, dev0.ch0's instance, and\n  dev5.ch1's instance separately, and we want to keep the passwords and\nuiid in sync, for clarity.  However, there are subtle differences that should\nbe tracked. This is like an overlay, in a way - but it's for the whole\ninstance (in a deploy sense), not just one of the software packages.\n\n### Directory Layout\n\n* SRC/\n  source checkouts - not separated by instance, assumes version tags are enough\n* BUILD/\n  out of source build trees, subdirectoried under $instance/\n* define/\n  instance definition files\n\n* extra/\n  extra files to be deployed\n* tmpl/\n  tmpl files to be rendered and then deployed\n\n\nTemplates\n---------\n\nAvailable structures are `instance` and `module`\n\nconfig file templates should be kept with the source repository as much as possible, so changes are versioned along with the code that uses them\n\n\nModules\n-------\n\nname: module name\ngenconfig: should facs genarate a config for this\nwrite_sql: <remove>\n\ndb::\n\nClass Overrides\n---------------\n\n_init_<system>\n\n\n\nNotes\n-----\n\nif project name matches a directory in deploy, rsync --delete is used to clean up the deploy",
    "lcname": "facsimile",
    "name": "facsimile",
    "github": true,
    "bugtrack_url": null,
    "license": "LICENSE.txt",
    "github_project": "facsimile",
    "summary": "UNKNOWN",
    "split_keywords": [],
    "author_email": "code@20c.com",
    "urls": [],
    "error": "Could not fetch GitHub repository",
    "cheesecake_installability_id": null
}
        
20C
Elapsed time: 0.00797s