Implement the base Hostmaster objects as entities

You're not getting a lot of extra value by doing this. If you just leave them as nodes, you get revisioning for free. Why would you convert them to entities?

I see what you're saying, but D6 node.module and D7 node.module are not the same things. You could use a field to denote the site type (drupal_site, static_site, etc). Another advantage of keeping things as nodes is that the Aegir 6.x -> 7.x upgrade path will be a LOT easier to deal with.

Tasks would be a good candidate for building an entity around. Don't need revisioning and all the extra stuff that node.module gives you for tasks. For servers, sites, and platforms though, I really think that staying with node.module is going to simplify things. You get an easy upgrade path. You get the node access framework (which is really useful, in my environment). While I can certainly identify with the urge to simply Aegir, I don't think doing a wholesale switch away from node.module is the way to do it.

I feel that leveraging the node access system is huge for us. If we switch away from nodes for sites, platforms and servers, we ditch all that. We also ditch the intuitive (for drupal users) approach of "create content", so I feel that we could keep those as nodes. What we should be leveraging there is the fields API: drop our custom code for all those parameters that are associated with those things and make stuff like the platform path, the site's client (and so on) be fields associated with nodes.

I do think tasks can be entities though, even though I am hesitant in abandoning the revisions of logs, although that is something we could keep in another way...

Packages are totally entities, no need to have them as nodes whatsoever.

Clients, in my mind, could become entities too, although I think we should look at how organic groups does it, because our clients are really like "og entities".

Regardless of what I think is right here, I think that the person doing the work should have the last word, although we should also consider who is going to maintain that code in the long term too. ;)

I think moving away from nodes to entities gives a lot more in the lines of oop, along with being able to be more granular and allow people to override defaults where needed.

I think everything in aegir should live as an entity, Clients, Servers, Packages, Sites, Platforms, and tasks. I think we should split off of the default permissions so that we can be more flexible with permissions, ie:

Clients, users assigned to clients, and users not assigned to clients could be respected as psuedo roles. leveraging the Entity API to allow extension of tasks, servers, platforms, sites, etc. would be awesome. I would be more than willing to provide time to work towards this.

using entities could lead us towards being able to support other cms sites besides drupal which would be a strong plus for the project.

Switching from nodes to entities just because it "gives a lot more in the lines of oop" is not a good reason. Nodes *are* entities with some extra stuff tossed in, like the node access system. There's no reason to make everything an entity just for the sake of doing so. I say this: take each of the Hostmaster object types (Clients, Servers, etc.) and carefully weigh the pros and cons of switching each to entities.

There's no reason that we have to switch all of the object types to entities, but I'm not necessarily against switching where it would be beneficial. Just doing an all-in conversion to entities seems wasteful though.

That is, nodes and entities are just tools. Pick the right one for the job, and don't try to use one or the other just because it's what the cool kids are doing.

Yes but at the same time servers, platforms, packages, and sites are Not nodes, they are not pieces of content. They are objects. Having more flexibility with the permissions system would be a good thing. Allowing for user associations/groups/organizations etc.

but you are right finding the right mix should be paramount. IMHO I think being able to encapsulate all of the Server / Platform / Site stuff into a class that can then be overrided to provide additional functionality is the strongest case for this. There may not be many out there doing the things I am doing with aegir and managing Wordpress/joomla/cakephp but it is a pain to do it with the current setup and hacky at best.

example being:

Class PlatformController {

public function getTaskList(){ /* Drupal related tasks, including verify */ }

}

Class JoomlaPlatformController extends PlatformController{

public function getTaskList(){ /* Joomla related tasks */ }

}

Class TaskController {

public function exec( ){
module_invoke_all('this_task_hook');
/* my tasks*/
}

}

etc

Yes but at the same time servers, platforms, packages, and sites are Not nodes, they are not pieces of content. They are objects. Having more flexibility with the permissions system would be a good thing. Allowing for user associations/groups/organizations etc.

You don't need to migrate away from nodes to make this happen. You can do all sorts of magic with node references.

IMHO I think being able to encapsulate all of the Server / Platform / Site stuff into a class that can then be overrided to provide additional functionality is the strongest case for this. There may not be many out there doing the things I am doing with aegir and managing Wordpress/joomla/cakephp but it is a pain to do it with the current setup and hacky at best.

You also don't need to encapsulate things in classes to make them flexible. We have *lots* of hooks that let you operate on nodes and respond to all sorts of events. I can imagine that wordpress/joomla/cakephp hosting with Aegir would be painful at best, but that's not because things aren't encapsulated in classes. It's because Aegir is not designed to handle that....not yet, anyways. Switching between different site types should be as easy as adding some options (Drupal, Wordpress, etc.) on the node form, and then responding appropriately in the node form submit hook.

We don't need custom entity types to have a flexible system.

I said override, not hooks. There is a big difference and you dont get the flexibility with hooks that you can get with being able to override default behavior. I dont want to use Node References, again these are not pieces of content at their core if we are talking about decentralization they need to be entities.

First, "content" can mean a variety of things. To me, it just means "not-configuration", so in Aegir's case, it doesn't matter HOW the hostmaster objects are stored, it's still content.

Secondly, you keep saying that for x to happen, they "need" to be entities. Why to they "need" to be entities? That is, what are some of the things that we haven't been able to do because we're not using Entities for all the hostmaster objects and why can't we do those things (what's blocking us)?

I will concede that you probably dont need everything as nodes. I would like to have the task as an entity, and possibly have some method of overriding what tasks are called for a type of Platform or Site, that along would be enough for me. If you have a suggestion as how to something like this would be capable, please provide some sort of example of how you would do it in the current system or in the system you envision for d7.

Okay, so tasks as entities makes sense (like I said in #3). If tasks were entities, you could just use hook_entity_view_alter.

right but it is more than just view, it would also have to deal with how/what it connects to on the back end. thus being able to override maybe platform and tasks would allow me to do this.

So i know i keep going back to this, but this is because i have use cases for this now and would like to manage it all inside of aegir.

Use case(s):

case 1: Drupal 7 site (Default Use case)

function hook_platform_type( ){
   return array( 
   'drupal7' => array(
    'tasks' => array(
     'verify' => 'drush_drupal7_provision_verify',
     'install' => 'drush_drupal7_provision_install',
     'migrate' => 'drush_drupal7_provision_migrate',
     /* etc, etc */
    )
   )
);
}

Then being able to define new types of platforms that can call specific verify, migrate, install, enable, disable, delete, etc tasks would allow us to build in support for other CMS platforms like Joomla, or CRMs like SugarCRM, etc. Possibly even building migration scripts from non drupal sites into drupal(which would be my ideal use case for most new customers).

If i could get the ability to define alternate tasks for platforms or define new types of platforms and be able to define a different set of tasks on sites that are hosted on those platforms I think i would be happy.

Just not sure how best it would be done with a node based system like we have now.

Oh, I see. Yeah, so basically we attach a platform/site type field to the appropriate content type, then act on it appropriately based on the value of the field. That doesn't really have anything to do with whether or not a given hostmaster object is an Entity or not, though. That's a different set of work entirely (it'd be nearly the same process if the hostmaster objects are nodes or entities).

Right only having some way that we still would have a single 'platform' node type, but it would act dynamically based on what code base you are trying to initialize. Not sure if automatic detection or manual selection would be the best method here. Maybe Automatic detection and fallback to Manual?

So if you have an Aegir install that has definitions for Drupal 5, 6, 7, 8 and Joomla 1. It would automatically know how to verify the platform. or it would run through each verify callback until it finds one that passes or errors out if none passes.

With this setup we could easily write drush command scripts specific to different CMS / CRMs. If thats acceptable i may start working on it some today.

This just in:
http://drupal.org/project/dns
Module to help administer your DNS records in Drupal. Will be built for Drupal 7 using the new entity system.

One concrete reason I can see to moving to entities would be #2049495: Move tasks from node_operations to actions. In hosting_site_action_info() we can only declare 'node' as the type currently:

  ...
    'hosting_site_backup_action' => array(
      'type' => 'node',
      'label' => t('Site: Backup'),
      'configurable' => FALSE,
    ),
  ...

This mean we should probably wrap our hook_TASK_action()'s in if (node->type == 'site') or something. Being able to call hosting_site_backup_action($site) would be better imo.

#23 only applies to site, platform and server nodes. We already block the direct creation and editing of tasks and packages, so those seem like natural moves to entities too, though I'd keep revisions for tasks, as it allows for our task log history.

As for needing node_access(), mentioned in #5, we need Entity API in Aegir3 anyway, for VBO, so we have entity_access() available. Besides, clients should become a OG entities, since OG already supports pretty much all the functionality we're looking for in clients. That's where we're doing all the funky node_grants()/node_access_records() stuff anyway.

Oh, also, the original blocker has been fixed in Entity API: #996696: Support revisions in Entity API So I'm in agreement with Steven about moving entirely to entities, though possibly not in the Aegir3 time-frame.

Hmm, there is no equivalent (that I've found anyway) for node_grants()/node_access_records() for entities. So we'll have to re-think our security model from the ground up in moving towards entities.

For reference, I've been thinking about this a bit lately, and I think a hosting_service entity may be a more useful than trying to define each of the current node-types as entities. I wrote up some preliminary ideas in https://www.drupal.org/node/2457425#comment-9894111