0.4 - make a cleaner API for "servers" (dbserver, webserver, dnsserver, ...)
| Project: | Hosting |
| Version: | 6.x-0.4-alpha1 |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
| Issue tags: | aegir-0.4, multiserver |
Jump to:
The work on DNS provisionning showed the need to abstract out the "server" types better. Right now, a new "dns server" node type is being created in the patch, and the patch needs to modify the platform table structure to map dns servers to platforms.
To quote issue #269931: nameserver provisioning:
2. the modifications to the hook_block() in should probably be factored out using a cleaner API. Same with the hosting_platform_form() hook, which should probably be form_alter()'d instead. hook_update() and hook_insert(), hook_view() are clearly a pain here, but should be overridden too, I don't know how.
3. hosting_node_help() has a similar issue. The content type should probably be defined by the module itself and not hosting.module. Similarly, web_server, platform and db_server could also define their own hook_help()
4. the modification to the hosting_platform table is trickier. I don't exactly know how to handle this with Drupal "modularly": can we just define a hook_update_N() that modifies the table of another module and leave it at that?
Basically, we need the following:
1. a hosting_platform_server table that maps servers to platforms
2. a hosting_server table that contains the various web, db, dns, etc servers, which are seperated by a "type" column
3. a generic hosting_server content type which can be extended
4. hooks in hosting_platform to allow grafting extra server types in a platform (maybe form_alter() is enough here?)
This should probably be undertaken after 0.1 is released for sanity reasons.
#1
Let's do this for 0.2.
#2
After discussion, this is more part of the 0.3 milestone, 'multiple server' feature:
11:50:01 <@Vertice> oh. and i'd like to add a server verify task11:50:05 <@Vertice> before the platform verify task
11:50:33 <@Vertice> which places the db / apache stuff into a server specific config
11:50:36 <@anarcat> may we should keep 'provision setup' in 0.2
11:50:41 <@anarcat> sorry, i got distracted
11:50:43 <@Vertice> so we dont need the mysql root pass etc in the platform
11:51:16 <@anarcat> yeah for verify server
11:51:34 <@anarcat> verify server would also be something that could check for Include in httpd.conf for example
11:51:39 <@Vertice> we should go as far as we can without having to unfuck webserver / dbserver etc.
11:51:41 <@Vertice> yes
11:52:08 <@anarcat> hum
11:52:14 <@Vertice> for dns server to be right tho
11:52:18 <@Vertice> we will need to unfuck it
11:52:20 <@anarcat> so i'm a bit confused about all this, but i feel your reasoning is sound
11:52:22 <@Vertice> ie: one server node
11:52:22 <@anarcat> yeah
11:52:27 <@Vertice> with multiple services on it
11:52:31 <@anarcat> spyd: there's a lot of unfucking to do in dns :)
11:52:39 <@anarcat> hum
11:52:42 <@anarcat> not sure about that though
11:52:49 <@Vertice> services aren't nodes
11:52:50 <@anarcat> maybe we don't need the 'server' abstraction
11:53:05 <@Vertice> anything we want to attach a taskt o
11:53:08 <@Vertice> needs to be a node
11:53:10 <@anarcat> services can have a hostname, which is all the 'server' abstraction we need
11:53:22 <@Vertice> not really
11:53:25 <@anarcat> what we call 'servers' now are really 'services on server'
11:53:25 <@Vertice> we need a server node type
11:53:30 <@Vertice> for handling 0.3 feature
11:53:30 <@anarcat> not sure about that
11:53:34 <@anarcat> which feature?
11:53:40 <@anarcat> multiple server?
11:53:46 <@anarcat> it's just different services
11:53:47 <@Vertice> ie: adding multiple servers
11:53:50 <@Vertice> communicating between them
11:54:11 <@anarcat> i feel 'servers' just add unnecessary complexity
11:54:32 <@anarcat> although there's a common ground between multiple services on the same server (ssh keys, for example)
11:54:34 <@anarcat> (and hostname)
11:54:36 <@Vertice> http://groups.drupal.org/node/18581
11:54:38 <goumbot> groups.drupal.org: Aegir 0.2 system layout | groups.drupal.org
11:54:38 <@anarcat> so i guess that makes sense
11:54:43 <@Vertice> yeah
11:54:50 <@Vertice> with servers being their own type
11:54:54 <@Vertice> having multiple services
11:54:58 <@Vertice> we reduce the node count
11:55:06 * anarcat nods
11:55:11 <@Vertice> and make it so a 'verify' task on a server configures all the services associated to it
11:55:18 <@anarcat> so that's some major rearchitecturing
11:55:21 <@anarcat> should that go in 0.2?
11:55:23 <@Vertice> yeah
11:55:27 <@anarcat> that sounds to be more 0.3 material
11:55:33 <@Vertice> well. only if we can't get around it
11:55:37 <@anarcat> yeah
11:55:41 <@anarcat> i wouldn't mark this as critical
11:55:49 <@Vertice> nope
11:55:53 <@anarcat> although i did before :)
11:55:54 <@anarcat> http://drupal.org/node/344967
11:55:56 <goumbot> drupal.org: make a cleaner API for "servers" (dbserver, webserver, dnsserver, ...) | drupal.org
11:55:57 <@anarcat> ..is crit
11:56:07 <@anarcat> so i would downgrade this to 'normal' and mark it as 0.3
11:56:09 <@Vertice> it might get a bit weird with doing verify on db server
11:56:13 <@Vertice> yup
11:56:25 <@Vertice> since now we can't do verify on db server
11:56:32 <@Vertice> and db server will need to be associated to web server
11:56:53 <@anarcat> okay, pasting that valuable exchange in the issue
#3
Thinking about links between server nodes:
11:57:35 <@anarcat> 11:56:32 <@Vertice> and db server will need to be associated to web server11:57:37 <@anarcat> does it really?
11:57:48 <@anarcat> or isn't the 'site' the association between the two?
11:57:53 <@anarcat> (same goes for dns)
11:59:31 <@anarcat> anyways, this is not priority for now, i guess
11:59:36 <@Vertice> no. it needs to be
11:59:41 <@Vertice> because we need to set up %host
11:59:49 <@Vertice> ie: these db servers need to be verified
11:59:52 <@anarcat> unless something in 0.2 is blocked by this, i suggest we move onto other things
11:59:57 <@Vertice> and these db servers need to have access added
12:00:12 <@anarcat> Vertice: but that access is based on the users created on the site
12:00:21 <@anarcat> there's no server-based trust between db and web servers
12:00:24 <@anarcat> at least we don't want that
12:00:32 <@anarcat> we want user-level accesses between db and web servers
12:00:43 <@anarcat> unless you talk about having physicaly/firewall level accesses configured
#4
I wrote some code for the denormalization of the package and package release node types (http://drupal.org/node/416550) that could form the basis for this work.
#5
Tagging for 0.3.
#6
#7
#8
This all looks like frontend stuff. The backend stuff is more in #586000: make a "server verify" task.