1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-25 16:22:43 +01:00
phorge-phorge/src/applications/phid/PhabricatorPHIDConstants.php

59 lines
1.8 KiB
PHP
Raw Normal View History

<?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 = '!!!!';
const PHID_TYPE_REPO = 'REPO';
const PHID_TYPE_CMIT = 'CMIT';
const PHID_TYPE_OPKG = 'OPKG';
const PHID_TYPE_PSTE = 'PSTE';
const PHID_TYPE_STRY = 'STRY';
const PHID_TYPE_POLL = 'POLL';
const PHID_TYPE_WIKI = 'WIKI';
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';
const PHID_TYPE_POST = 'POST';
const PHID_TYPE_TOBJ = 'TOBJ';
const PHID_TYPE_BLOG = 'BLOG';
const PHID_TYPE_QUES = 'QUES';
const PHID_TYPE_ANSW = 'ANSW';
const PHID_TYPE_MOCK = 'MOCK';
const PHID_TYPE_MCRO = 'MCRO';
const PHID_TYPE_CONF = 'CONF';
const PHID_TYPE_CONP = 'CONP';
const PHID_TYPE_PVAR = 'PVAR';
2013-03-28 17:10:34 +01:00
const PHID_TYPE_ACNT = 'ACNT';
const PHID_TYPE_PDCT = 'PDCT';
const PHID_TYPE_PRCH = 'PRCH';
const PHID_TYPE_PAYM = 'PAYM';
const PHID_TYPE_CHRG = 'CHRG';
const PHID_TYPE_CART = 'CART';
const PHID_TYPE_CDWN = 'CDWN';
const PHID_TYPE_LEGD = 'LEGD';
const PHID_TYPE_LEGB = 'LEGB';
const PHID_TYPE_XACT = 'XACT';
const PHID_TYPE_XCMT = 'XCMT';
const PHID_TYPE_XUSR = 'XUSR';
const PHID_TYPE_BOOK = 'BOOK';
const PHID_TYPE_ATOM = 'ATOM';
const PHID_TYPE_AUTH = 'AUTH';
const PHID_TYPE_XOBJ = 'XOBJ';
Provide "builtin" files and use them to fix Pholio when files are deleted Summary: Fixes T3132. Currently, if a user deletes a file which is present in a mock, that mock throws an exception when loading. If the file is also the cover photo, the mock list throws an exception as well. In other applications, we can sometimes deal with this (a sub-object vanishing) by implicitly hiding the parent object (for example, we can just vanish feed stories about objects which no longer exist). We can also sometimes deal with it by preventing sub-objects from being directly deleted. However, neither approach is reasonable in this case. If we vanish the whole mock, we'll lose all the comments and it will generally be weird. Vanishing a mock is a big deal compared to vanishing a feed story. We'll also need to load more data on the list view to prevent showing a mock on the list view and then realizing we need to vanish it on the detail view (because all of its images have been deleted). We permit total deletion of files to allow users to recover from accidentally uploading sensitive files (which has happened a few times), and I'm hesitant to remove this capability because I think it serves a real need, so we can't prevent sub-objects from being deleted. So we're left in a relatively unique situation. To solve this, I've added a "builtin" mechanism, which allows us to expose some resource we ship with as a PhabricatorFile. Then we just swap it out in place of the original file and proceed forward normally, as though nothing happened. The user sees a placeholder image instead of the original, but everything else works reasonably and this seems like a fairly acceptable outcome. I believe we can use this mechanism to simplify some other code too, like default profile pictures. Test Plan: Deleted a Pholio mock cover image's file. Implemented change, saw functional Pholio again with beautiful life-affirming "?" art replacing soul-shattering exception. Reviewers: btrahan, chad Reviewed By: chad CC: aran Maniphest Tasks: T3132 Differential Revision: https://secure.phabricator.com/D5870
2013-05-09 03:12:52 +02:00
const PHID_TYPE_VOID = 'VOID';
const PHID_VOID = 'PHID-VOID-00000000000000000000';
}