Project:Hostmaster (Aegir)
Version:7.x-3.x-dev
Component:Code
Category:task
Priority:normal
Assigned:Unassigned
Status:needs work

Issue Summary

How can I get involved?

Have a look at the list of issues below, and find one that you like the look of and try to progress it a little, you don't have to complete the issue, you can just post a helpful comment, make a diagram, etc. You can chat to the Hostmaster maintainers via IRC if you need guidance on what issues to look at.

Provision

Provision is independent of Drupal (since it's just Drush extensions) so there's nothing to do there.

Eldir

The theme has already been ported to D7, it's in the 7.x-3.x branch of the eldir project. See #1907010: Port Eldir to D7 for more information.

Hostmaster

There is a preliminary port of the install profile in the 7.x-2.x branch of hostmaster. See #1455232: Create a basic install profile for Hostmaster for more information.

Hosting

This is the big one, we're going to take the opportunity to completely rewrite Aegir's codebase, updating it to use modern Drupal techniques, like entities and views! - the rewrite has been postponed to the D8 port. For now, we are looking at doing a straight port without a rewrite.

We need to redo the roadmap here because the roadmap below assumed we were going to rewrite everything.

Roadmap/remaining tasks

We are using this issue to co-ordinate efforts around the D7 rewrite, please don't discuss the nitty gritty issues here, but discuss broader issues. As we create issues for D7, please add them to the list below so we can keep a clear roadmap in place.

See the list of issues below for work outstanding and where you can get involved if you'd like help out. Note: this roadmap needs to be updated as most issues regarding the entities port are now postponed to D8.

Issue Status
#1907010: Port Eldir to D7 Completed!
#1455232: Create a basic install profile for Hostmaster Done, but ergonlogic wants a second look
#1455216: Implement the base Hostmaster objects as entities Postponed to the D8 port
#1455266: Work out what fields and properties we need on servers Postponed to the D8 port
#1455292: Work out what fields and properties we need on platforms Postponed to the D8 port
#1455284: Work out what fields and properties we need on sites Postponed to the D8 port
#610040: Add X links on listing pages Awaiting work on other issues
#1373152: Make the name of 'clients' configurable Awaiting work on other issues

Infrastructure/process issues

Issue Status
#1435144: get rid of the debian branch, make a native package done!
#1975454: Create dev release node for 7.x-3.x

Comments

#1

I've created issues for the "core required" Aegir modules, which should probably be our priority. I figure these are:

  • hosting
  • package
  • platform
  • server
  • site
  • task

I'll leave the rest alone for now, so as not to clutter the issue queue.

#2

Thanks for writing this up!

Just thinking out loud, but does it make sense to have a 7.x-1.x branch, that has feature parity with 6.x-1.x and is basically a straight port? 7.x-2.x then becomes the new hotness afterwards.

#3

I am not sure we have the manpower to maintain 3 branches at a time. I would rather keep D7 as one of the features of 2.x than try to push three release branches at the same time...

Anyways, as things stand now, 2.x is pretty close to 1.x in terms of features and if we concentrate on the D7 port, I feel that is pretty much what it's going to be. :)

We could, however, have a feature branch for D7... but I would try to merge it in as soon as it's functional. Same for Drush 5 support, btw.

#4

I'm going to port Eldir!

#5

So I've worked on a 'harness' for porting Eldir (will open a different issue for that) that is basically a D7 implementation of the main tables and forms in Aegir, you can build it using the stub here:

http://drupal.org/sandbox/darthsteven/1267494

#6

I've made the 7.x-2.x branch actually use Drupal 7, which means that branch is totally broken now, but there's a 6.x-2.x for those that want new stuff, but not Drupal 7. It just makes more sense that way.

The Eldir theme has been ported and committed to Hostmaster 7.x-2.x.

#7

Version:6.x-1.x-dev» 7.x-2.x-dev

#8

Subscribing.

#9

Me too ))

#10

subscribe
#spam

#11

@skwashd - you can follow issues now, no need to subscribe anymore! sorry for the spam.

#12

Title:META: D7 port of Aegir» META: D7 rewrite of Aegir roadmap
Assigned to:Anonymous» Steven Jones

Changing title to reflect what we're actually going to do, and assigning it to me so it's clear that I have ownership of this initiative.

#13

Title:META: D7 rewrite of Aegir roadmap» Roadmap: D7 rewrite of Aegir

#14

Status:active» postponed (maintainer needs more info)

So we pretty much decided over on the community site to put the D7 port on hold, and do a D8 port instead!

#15

Title:Roadmap: D7 rewrite of Aegir» Roadmap: D8 rewrite of Aegir

#16

Assigned to:Steven Jones» Anonymous

#17

Title:Roadmap: D8 rewrite of Aegir» Roadmap: D7 rewrite of Aegir

Er, okay, I'm glad this discussion happened where people could actually see it and participate.

I'd really love to have the frontend of Aegir implemented in Drupal 7, using entities and fields etc. But it's a massive task to re-write Aegir, in fact I'm not sure we'll be able to complete until summer 2013, which is when D8 is supposed to be release. So at that point, do we just port to D8 (hopefully a lot less painful)?
It seems that porting to D7 is splitting our focus and resources maybe, if we switched to just saying, new features go into 6.x-2.x, and we just have a good year or so of building on Aegir and making it better and more refined. We can use the time to clean up 6.x-2.x and make the code base cleaner and organised better etc.
Then at some point, when D8 hits feature freeze we start building the frontend on top of D8, and after it comes out we release too.

This is madness. Think about this timeline a bit more: D6 will be EOL and unsupported by the time Aegir is released on top of Drupal 8. Most of the things that we'd have to do for a D8 rewrite are nearly identical for what we'd have to do for a D7 rewrite (converting some things to Entities, cleaning up the code, perhaps replacing all the hardcoded lists with Views, etc). Telling people that they have to install a really old version of Drupal just to run Aegir just won't do. I really hate that I have to run Drupal 6 to be able to use Aegir, and I suspect that there are some other people in that boat as well.

If you guys don't want to rewrite the frontend on Drupal 7, then fine. But don't completely discard the idea of a D7 port - it's still important, even if it's a lot of work. I don't think it will be that bad and I'd be happy to look at certain components over the next few months. Worst case, I'll try to gather up some funding to get a developer paid to do the upgrade.

Hell, if you would have announced this a week ago, I would have submitted a GSoC project for it >.<

#18

Status:postponed (maintainer needs more info)» postponed

This is marked postponed (clarified the status while I'm here), which means anyone is free to pick this up and run. Code is gold.

We, on the other hand, have plenty of other stuff on our hands to run with, so we're focusing on what seems really important right now.

Note that you usually don't "install drupal" yourself to run aegir, it installs it for you, and in a dedicated platform anyways, so I don't see this as being so much of an issue.

#19

This is marked postponed (clarified the status while I'm here), which means anyone is free to pick this up and run. Code is gold.
We, on the other hand, have plenty of other stuff on our hands to run with, so we're focusing on what seems really important right now.

Sure, I can understand prioritization, but throwing out the D7 port just seems silly. Most of the things that will have to be done for a D8 port will also have to be done for a D7 port. IMO, doing the D7 port helps to line the system up for an easy-ish D8 port.

Note that you usually don't "install drupal" yourself to run aegir, it installs it for you, and in a dedicated platform anyways, so I don't see this as being so much of an issue.

I'm aware of that, but the fact that I have a Drupal 6 installation sitting around drives me nuts. I won't even install Open Atrium anymore because of that reason.

#20

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.

#21

What is the status on this project? It seems the aegir community is hard at work moving towards d7 but this thread seems to indicate the next drupal ready aegir platform will be for d8?

#22

As far as I know, no one is working on the D7 rewrite.

#23

I started on it, but have been slammed lately, so I haven't been able to work on it as much as I'd have liked.

#24

Awesome news! Please consider publishing your work to a sandbox so that it is not lost if you stop again. :) Are you starting from the current d7 rewrite branch (7.x-2.x)?

#25

Just to clarify the current situation: we are *not* giving up on the port to D7. If someone wants to rush this for Aegir 2, it would even be welcome, but I am doubtful that a port would be possible by the time we want to release 2.x (that is: real soon now).

We are not going to do the full entities port however - we will just do a minimal port to ensure continuity and keep the rewrite for an eventual D8 port, in Aegir 3 or 4.

So ideally, Aegir 2 would be Drupal 7 and Aegir 3 Drupal 8, but we don't want to wait that long to release Aegir 2, so it's mostl likely going to be:

  • Aegir 2: Drupal 6, short-lived
  • Aegir 3: Drupal 7, trivial port
  • Aegir 4: Drupal 8, rewrite with entities and so on

#26

Title:Roadmap: D7 rewrite of Aegir» Roadmap: D7 port of Aegir
Status:postponed» needs work

For the past couple weeks, we've been working on a port of Hostmaster to Drupal 7. We're happy to say that we've made a lot of progress, and have basic functionality working (and even a couple of enhancements already)! Here's a high-level plan for the port, showing our progress so far:

  1. Run hostmaster through coder_upgrade
  2. Ensure hostmaster-install works
  3. Ensure 'core' functionality works ('verify server', 'create platform' & 'install site'...)
  4. Add (Selenium) tests of 'core' functionality
  5. Ensure rest of Aegir functionality works and is covered by tests
  6. Merge into active dev branches

We've pushed 7.x-3.x branches to both Hostmaster and Provision, and we're currently proceeding with integrating Selenium into our testing infrastructure.

#27

So while I think that adding Selenium tests for the full Aegir stack is a good idea, I wonder if we could add normal Drupal simpletests and get it working somehow.

#28

Let's move discussion on testing back over to #1080590: Testing [meta] :)

#29

@anarcat
will our installs be able to upgrade from 1.x to 3.x and bypass 2.x?

#30

@marafa - usually not. Aegir is designed to be upgraded to skip minor but not major versions.

#31

Lets discuss how we merge code from 6.x-2.x to 7.x-3.x...

Ideal would be to only work on 3.x and backport important fixes... but work on 2.x is still ongoing to get it stable.

I'd hate to lose work.
@Steven Jones or @ergonlogic: would you be willing to merge in the recent 2.x commits for the time being? Or should the committer be responsible to get it it 3.x?

#32

Good point, @helmo.

In my opinion, we should focus on getting 2.0 released, and I wouldn't want to slow that down by asking for patches to 3.x and then backporting to 2.x. Especially since 3.x is only barely functional at the moment. However, that's obviously the best idea once we release 2.0.

I'll make some time to look at merging the recent 2.x changes into the 3.x branch, and then keeping them aligned.

#33

Can't we just git merge the trees?

Aka git co 7.x-3.x ; git merge 6.x-2.x?

#34

@anarcat, that's largely the plan, but any db code changes will likely need to be adapted, etc.

#35

I merged 6.x-2.x into 7.x-3.x, and I'll do so at least for each pre-release that we do.

#36

Version:7.x-2.x-dev» 7.x-3.x-dev

Setting the correct version.

#37

I guess we would also want to consider support for Drush 8.x-6.x as that is in beta now

#38

adding tag to be able to hunt down other similar issues.

#39

alright, i got rid of all the other instances of that tag - we should now use 7.x-3.x-dev for all 3.x issues.