Following up on #1468874: Split Eldir back out to a stand-alone project, we are thinking of splitting off hosting into a separate module back again.

The advantages are:

  1. people can more easily override the install profile by simply building their own and including hosting into it
  2. usage statistics will be published
  3. proper version numbers will be available here

The disadvantages are:

  1. we'll need to create more release nodes (see #1050618: Publish release nodes with tag message from corresponding Git tag to ease this)
  2. we have to change the hostmaster.make at every hosting release
  3. people will still be confused as to where to report issues

I am not sure it is worth it, and this will not be part of alpha1 just yet.

Comments

ergonlogic’s picture

The advantages speak for themselves, but I'll see if I can't rebut some of those disadvantages.

1. we'll need to create more release nodes

Yep, and that issue seems blocked on work in the 'project' project, and isn't linked to an issue under 'project', so it may be a while. Can we automate creating release nodes with Jenkins, maybe?

2. we have to change the hostmaster.make at every hosting release

The two should probably be kept in sync, no? Even though hostmaster doesn't change much, it'll have to track changes in hosting.

3. people will still be confused as to where to report issues

People will likely always be confused by this. Short of starting an 'aegir' project just to triage issues, I don't see that this'll change.

anarcat’s picture

Yep, and that issue seems blocked on work in the 'project' project, and isn't linked to an issue under 'project', so it may be a while. Can we automate creating release nodes with Jenkins, maybe?

That would require an account on Drupal.org with admin access to the projects.. Not sure Drupal.org people would like that. But it's an idea!

The two should probably be kept in sync, no? Even though hostmaster doesn't change much, it'll have to track changes in hosting.

Hm... not necessarily. We *could* make the hostmaster.make file follow the latest hosting module, by not specifying a version, for example. Otherwise, yes, that means we need to release both every time.

I was hoping we could desynchronise away the hostmaster profile, since very little work happens there, the same way we don't need a new eldir release at every hosting release...

ergonlogic’s picture

Status: Active » Reviewed & tested by the community

We *could* make the hostmaster.make file follow the latest hosting module, by not specifying a version...

To get a fixed platform build, a downstream makefile could just do:

includes[hostmaster] = "hostmaster.make"
projects[hosting][version] = 2.0-alpha2

So, I don't see any reason not to de-syncronise the components.

anarcat’s picture

Status: Reviewed & tested by the community » Needs work

The problem here is that this will simply break "dev builds" - if the makefile specifies "use the latest version", then it will download the latest *stable* version and we won't be able to install aegir out of the box from git, unless we use a custom makefile.

In other words, hostmaster from git will not install hosting from git, but from stable. Ouch.

ergonlogic’s picture

Well, we can pass in custom makefiles, right? To both 'hostmaster-install' and the .debs.

So, we could ship with a hostmaster-dev.make that has something like:

includes[hostmaster] = "hostmaster.make"
projects[hosting][download][type] = 'git'
projects[hosting][download][url] = '...'

Could that work?

anarcat’s picture

Ah that's a good idea! Yes, it could just work! Then we'd need to fix the build scripts and documentation, otherwise this seems like a good idea.

ergonlogic’s picture

I think this was partially blocked by #1917614: give ergonlogic access to the hosting module. That is, we didn't have control over adding maintainers to Hosting project. That's been fixed now though.

anarcat’s picture

Assigned: Unassigned » anarcat

i did this:

 1004  git clone hostmaster hosting
 1005  cd hosting
 1006  git tag -l
 1007  git tag -l | xargs git tag -d
 1008  git filter-branch --tag-name-filter cat --prune-empty --subdirectory-filter modules/hosting/ HEAD
 1009  git update-ref -d refs/original/refs/heads/6.x-2.x
 1010  git remote rm origin
 1011  git reflog expire --expire=now --all
 1012  git gc --aggressive
 1013  git prune
 1014  ls
 1015  git remote add origin anarcat@git.drupal.org:project/hosting.git
 1016  git fetch origin

then i tried to do similar rebase than in the eldir mergeback, and failed:

anarcat@angela:hosting$ git rebase -p --onto origin/master --root
error: could not apply e8ae7b6... merge hosting into hostmaster

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".
Could not pick e8ae7b65ca8d9ca7ea6056c1e602dae810a08adf
anarcat@angela:hosting$ git co --theirs .
anarcat@angela:hosting$ git add .
anarcat@angela:hosting$ git rebase --continue
emacsclient: can't find socket; have you started the server?
To start the server in Emacs, type "M-x server-start".
[detached HEAD c2fb7d0] merge hosting into hostmaster
 27 files changed, 27 insertions(+)
Auto-merging client/hosting_client.access.inc
CONFLICT (content): Merge conflict in client/hosting_client.access.inc
Automatic merge failed; fix conflicts and then commit the result.
Error redoing merge e44a18648a1aa15eb1c03fd7da47b090d51a3ebf

I gave up there again, not sure why this is failing, again. So we just have a disconnected branch and that's it...

anarcat@angela:hosting$ git push -u origin 6.x-2.x
Counting objects: 4782, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (1230/1230), done.
Writing objects: 100% (4782/4782), 716.91 KiB | 76 KiB/s, done.
Total 4782 (delta 3605), reused 4701 (delta 3550)
To anarcat@git.drupal.org:project/hosting.git
 * [new branch]      6.x-2.x -> 6.x-2.x
Branch 6.x-2.x set up to track remote branch 6.x-2.x from origin.

Now we need to change the makefile and remove the code from hostmaster.

anarcat’s picture

i have also moved over the 3.x branch. the remaining dev branches are ignored and left over to rot over to the hostmaster side. those includes the views integration stuff (#588728: Meta: Views integration redux), which will be rerolled in the hosting repo, and dev-1205458-move_sites_out_of_platforms (#1205458: Move modules/themes/libraries/files/private directories out of /sites/example.com), which will be rerolled if necessary. Other feature branches are either merged in or older than 12 months so considered dead.

anarcat’s picture

Priority: Normal » Major

so this is only partly done. the problem we're having now is that a hostmaster install doesn't follow tags, unless we edit the hostmaster.make file on release, which is annoying (but may be the only option).

i reverted some work I tried to do to workaround all this, to quote:

commit b81a646063e123b106858d80c6976716edca91dd
Author: Antoine Beaupré <anarcat@koumbit.org>
Date:   Thu May 16 19:03:39 2013 -0400

    revert last changes to release process

    we are keeping the old method of installing from git, which means we
    will install post-alpha2 code when there are commits to the frontend,
    but meh - we currently can't install alpha2 at all from git, so that's
    better.

    we at least need to download the hostmaster profile in aegir.make, but
    then that means it will recurse into hostmaster.make, so it means we
    need to fiddle with *that* code if we want have sticky branches there.

    the other alternative is to build from the distribution, but that's
    not supported by Drush make, only by pm-download.

we may postpone the proper fix to a latter alpha release, since this "works" now, it just installs any latest 2.x code...

anarcat’s picture

Status: Needs work » Fixed

so this works: we have split hosting, now the only thing that remains is the release process, for which i'll create another issue (#2002114: fix release process and scripts).

Status: Fixed » Closed (fixed)

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