2011-03-03 03:58:21 +01:00
|
|
|
<?php
|
|
|
|
|
|
|
|
|
|
final class PhabricatorPHIDConstants {
|
|
|
|
|
|
|
|
|
|
const PHID_TYPE_USER = 'USER';
|
|
|
|
|
const PHID_TYPE_MLST = 'MLST';
|
|
|
|
|
const PHID_TYPE_DREV = 'DREV';
|
|
|
|
|
const PHID_TYPE_TASK = 'TASK';
|
|
|
|
|
const PHID_TYPE_FILE = 'FILE';
|
|
|
|
|
const PHID_TYPE_PROJ = 'PROJ';
|
|
|
|
|
const PHID_TYPE_UNKNOWN = '????';
|
|
|
|
|
const PHID_TYPE_MAGIC = '!!!!';
|
2011-03-07 07:29:22 +01:00
|
|
|
const PHID_TYPE_REPO = 'REPO';
|
|
|
|
|
const PHID_TYPE_CMIT = 'CMIT';
|
2011-04-04 07:23:31 +02:00
|
|
|
const PHID_TYPE_OPKG = 'OPKG';
|
2011-06-10 08:53:53 +02:00
|
|
|
const PHID_TYPE_PSTE = 'PSTE';
|
2011-07-05 17:35:18 +02:00
|
|
|
const PHID_TYPE_STRY = 'STRY';
|
2011-07-08 20:13:11 +02:00
|
|
|
const PHID_TYPE_POLL = 'POLL';
|
2011-07-11 17:54:22 +02:00
|
|
|
const PHID_TYPE_WIKI = 'WIKI';
|
2011-07-17 03:44:48 +02:00
|
|
|
const PHID_TYPE_APRJ = 'APRJ';
|
Drydock Rough Cut
Summary:
Rough cut of Drydock. This is very basic and doesn't do much of use yet (it
//does// allocate EC2 machines as host resources and expose interfaces to them),
but I think the overall structure is more or less reasonable.
== Interfaces
Vision: Applications interact with Drydock resources through DrydockInterfaces,
like **command**, **filesystem** and **httpd** interfaces. Each interface allows
applications to perform some kind of operation on the resource, like executing
commands, reading/writing files, or configuring a web server. Interfaces have a
concrete, specific API:
// Filesystem Interface
$fs = $lease->getInterface('filesystem'); // Constants, some day?
$fs->writeFile('index.html', 'hello world!');
// Command Interface
$cmd = $lease->getInterface('command');
echo $cmd->execx('uptime');
// HTTPD Interface
$httpd = $lease->getInterface('httpd');
$httpd->restart();
Interfaces are mostly just stock, although installs might add new interfaces if
they expose different ways to interact with resources (for instance, a resource
might want to expose a new 'MongoDB' interface or whatever).
Currently: We have like part of a command interface.
== Leases
Vision: Leases keep track of which resources are in use, and what they're being
used for. They allow us to know when we need to allocate more resources (too
many sandcastles on the existing hosts, e.g.) and when we can release resources
(because they are no longer being used). They also give applications something
to hold while resources are being allocated.
// EXAMPLE: How this should work some day.
$allocator = new DrydockAllocator();
$allocator->setResourceType('sandcastle');
$allocator->setAttributes(
array(
'diffID' => $diff->getID(),
));
$lease = $allocator->allocate();
$diff->setSandcastleLeaseID($lease->getID());
// ...
if ($lease->getStatus() == DrydockLeaseStatus::STATUS_ACTIVE) {
$sandcastle_link = $lease->getInterface('httpd')->getURI('/');
} else {
$sandcastle_link = 'Still building your sandcastle...';
}
echo "Sandcastle for this diff: ".$sandcastle_link;
// EXAMPLE: How this actually works now.
$allocator = new DrydockAllocator();
$allocator->setResourceType('host');
// NOTE: Allocation is currently synchronous but will be task-driven soon.
$lease = $allocator->allocate();
Leases are completely stock, installs will not define new lease types.
Currently: Leases exist and work but are very very basic.
== Resources
Vision: Resources represent some actual thing we've put somewhere, whether it's
a host, a block of storage, a webroot, or whatever else. Applications interact
through resources by acquiring leases to them, and then getting interfaces
through these leases. The lease acquisition process has a side effect of
allocating new resources if a lease can't be acquired on existing resources
(e.g., the application wants storage but all storage resources are full) and
things are configured to autoscale.
Resources may themselves acquire leases in order to allocate. For instance, a
storage resource might first acquire a lease to a host resource. A 'test
scaffold' resource might lease a storage resource and a mysql resource.
Not all resources are auto-allocate: the entry-level version of Drydock is that
you manually allocate a couple boxes and configure them through the web console.
Then, e.g., 'storage' / 'webroot' resources allocate on top of them, but the
host pool itself does not autoscale.
Resources are completely stock, they are abstract shells representing any
arbitrary thing.
Currently: Resource exist ('host' only) but are very very basic.
== Blueprints
Vision: Blueprints contain instructions for building interfaces to, (possibly)
allocating, updating, managing, and destroying a specific type of resource in a
specific location. One way to think of them is that they are scripts for
creating and deleting resources. For example, the LocalHost, RemoteHost and
EC2Host blueprints can all manage 'host' resources.
Eventually, we will support more types of resources (storage, webroot,
sandcastle, test scaffold, phacility deployment) and more providers for resource
types, some of which will be in the Phabricator mainline and some of which will
be custom.
Blueprints are very custom and specific to application types, so installs will
define new blueprints if they are making significant use of Drydock.
Currently: They exist but have few capabilities. The stock blueprints do nearly
nothing useful. There is a technically functional blueprint for host allocation
in EC2.
== Allocator
This is just the actual code to execute the lease acquisition process.
Test Plan: Ran "drydock_control.php" script, it allocated a machine in EC2,
acquired a lease on it, interfaced with it, and then released the lease. Ran it
again, got a fresh lease on the existing resource.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran
Differential Revision: https://secure.phabricator.com/D1454
2012-01-11 20:18:40 +01:00
|
|
|
const PHID_TYPE_ACMT = 'ACMT';
|
|
|
|
|
const PHID_TYPE_DRYR = 'DRYR';
|
|
|
|
|
const PHID_TYPE_DRYL = 'DRYL';
|
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server
Summary:
adds a Phabricator OAuth server, which has three big commands:
- auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri
- token - given a valid authorization code, this command returns an authorization token
- whoami - Conduit.whoami, all nice and purdy relative to the oauth server.
Also has a "test" handler, which I used to create some test data. T850 will
delete this as it adds the ability to create this data in the Phabricator
product.
This diff also adds the corresponding client in Phabricator for the Phabricator
OAuth Server. (Note that clients are known as "providers" in the Phabricator
codebase but client makes more sense relative to the server nomenclature)
Also, related to make this work well
- clean up the diagnostics page by variabilizing the provider-specific
information and extending the provider classes as appropriate.
- augment Conduit.whoami for more full-featured OAuth support, at least where
the Phabricator client is concerned
What's missing here... See T844, T848, T849, T850, and T852.
Test Plan:
- created a dummy client via the test handler. setup development.conf to have
have proper variables for this dummy client. went through authorization and
de-authorization flows
- viewed the diagnostics page for all known oauth providers and saw
provider-specific debugging information
Reviewers: epriestley
CC: aran, epriestley
Maniphest Tasks: T44, T797
Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
|
|
|
const PHID_TYPE_OASC = 'OASC';
|
|
|
|
|
const PHID_TYPE_OASA = 'OASA';
|
2012-04-12 22:09:04 +02:00
|
|
|
const PHID_TYPE_POST = 'POST';
|
2012-07-09 19:39:14 +02:00
|
|
|
const PHID_TYPE_TOBJ = 'TOBJ';
|
2012-07-19 18:03:10 +02:00
|
|
|
const PHID_TYPE_BLOG = 'BLOG';
|
2012-08-10 19:44:04 +02:00
|
|
|
const PHID_TYPE_QUES = 'QUES';
|
|
|
|
|
const PHID_TYPE_ANSW = 'ANSW';
|
Add very basic scaffolding for Pholio
Summary:
I'm not going to land this until it's a bit more fleshed out since it would just confuse users, but this is probably more reviewable as a few diffs adding a couple features than one ULTRA-diff adding everything. Implement application basics for Pholio. This does more or less nothing, but adds storage, subscribe, flag, markup, indexing, query basics, PHIDs, handle loads, a couple of realy really basic controllers, etc.
Basic hierarchy is:
- **Moleskine**: Top-level object like a Differential Revision, like "Ponder Feed Ideas".
- **Image**: Each Moleskine has one or more images, like the unexpanded / expanded / mobile / empty states of feed.
- **Transaction**: Comment or edit, like Maniphest. I generally want to move most apps to a transaction model so we can log edits.
- **PixelComment**: Equivalent of an inline comment.
Test Plan: Created a fake object and viewed it.
Reviewers: btrahan, chad
Reviewed By: btrahan
CC: aran, davidreuss
Maniphest Tasks: T2097
Differential Revision: https://secure.phabricator.com/D3817
2012-11-22 02:22:36 +01:00
|
|
|
const PHID_TYPE_MOCK = 'MOCK';
|
|
|
|
|
|
2011-03-03 03:58:21 +01:00
|
|
|
}
|
