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.

Comments

anarcat’s picture

Priority: Normal » Critical

Let's do this for 0.2.

anarcat’s picture

Title: make a cleaner API for "servers" (dbserver, webserver, dnsserver, ...) » 0.3 - make a cleaner API for "servers" (dbserver, webserver, dnsserver, ...)
Priority: Critical » Normal

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 task
11: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
anarcat’s picture

Thinking about links between server nodes:

11:57:35 <@anarcat> 11:56:32 <@Vertice> and db server will need to be associated to web server
11: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
adrian’s picture

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.

anarcat’s picture

Tagging for 0.3.

anarcat’s picture

Version: 5.x-0.1-beta2 »
Issue tags: +aegir-0.4
adrian’s picture

Title: 0.3 - make a cleaner API for "servers" (dbserver, webserver, dnsserver, ...) » 0.4 - make a cleaner API for "servers" (dbserver, webserver, dnsserver, ...)
anarcat’s picture

Project: Provision » Hosting
Version: » 6.x-0.4-alpha1
Issue tags: +multiserver

This all looks like frontend stuff. The backend stuff is more in #586000: make a "server verify" task.

adrian’s picture

Status: Active » Needs work

a lot of this stuff is in the dev-server_node_type branch on git.aegirproject.org

what's left there is to fix / reimplement the command line creation. Because the existing modules (web_server etc) aren't exactly mapping to how the information is passed to the dispatch command anymore, that needs to be refactored a bit.

secondly, we need to refactor the install wizard to take into account the fact that there are different forms and smaller node types now.

Once that is done, and the front end and back in are communicating properly, i will want to merge back in with master and start work on #586000: make a "server verify" task

adrian’s picture

i rebased, and solved those last two issues.

this has broken installs with external database servers though, and we need to refine it some more in the case of multiple servers being used.

adrian’s picture

Status: Needs work » Fixed

merged this with the master branch.

additional issues should be new tickets. This likely breaks a whole bunch of stuff =)

the ui still needs some work.

Status: Fixed » Closed (fixed)
Issue tags: -aegir-0.4, -multiserver

Automatically closed -- issue fixed for 2 weeks with no activity.