introduce 'team', as an indirection between users and instances

[rade]

Following #581, users will have access to multiple instances, and instances can be accessed by multiple users.

That becomes a bit of a headache quite quickly:

• teams working on multiple systems need to invite each team member to each new instance
• teams working on multiple systems need to invite each new team member to each instance

Furthermore, the notion of teams is very common across other services, such as github, CI systems, issue trackers, etc, etc. So new users to Weave Cloud will likely miss it.

[rade]

At a minimum this requires

• a many-to-one relationship between instances and teams
• a many-to-one relationship between users and teams

though the latter is likely too constraining and needs to be a many-to-many.

To satisfy the main use case, the invitation feature will need to move from 'instance' to 'team'. As a corollary, the 'uninvite' feature - denying users access to instances - should also move. Creation and deletion of instances moves to 'team' too.

A user's list of accessible instances should indicate the team, e.g. group the instances by team.

Any user can create teams, and, delete teams they have access to. The latter should probably just mark them as disabled and disable access by probes with team instances' tokens. Later we can then add some way to resurrect disabled teams.

As with instances at present, team names should be random. We can improve on that later.

[paulbellamy]

My opinion is that teams should be similar to github. Where they are many-to-many from users to instances. This means we want something akin to a github organization to contain all these.

[pidster]

+1 for GitHub-like behaviour.

[paulbellamy]

Related: https://docs.google.com/document/d/1ovmzF8_wO4YWTQSNV2KEHPz0I8RXUsWA91AVGFQxyf8/edit

[paulbellamy]

Will have to fix the following as part of this:
#753
#723

This will fix:
#637

[rbruggem]

A few notes:

Billing

• Name: organization external id -> team external_id (for migration purposes, organization external id can be equal to team external id for existing zuora accounts).

• Zuora's 'Contract Effective Date'-> team.trial_expires_at date

• Usage data: two options:

  1. Breakdown per instance: found no easy solution.
     • Only way to maintain instance granularity in invoices would be to have different zuora charge ids (not straightforward)
  2. All instances in one charge (1 invoice item for all instances, per billing period)
     • merge aggregate data for all team instances to produce one report before sending to zuora

• Enabling/Disabling can be kept at instance level, it's simple. Can be expanded later.

UI

• Instance page to show all instances belonging to a team.

• Billing page, 2 options:

1. • billing page should be global and not grouped within an instance setting section
   • Usage section should be granular by instance
2. • billing page stays within in instance setting section
   • Account status and Payment method and invoice in another 'global' page.

• Team page should also be global and not within an instance setting.

• URL stay the same, showing instance name.

• Admin - add team page

[rade]

Instance page to show all instances belonging to a team.

Isn't that just https://cloud.weave.works/instances?

[rade]

Isn't that just https://cloud.weave.works/instances?

Except when we allow many-many team-user mappings. Regarding that, I reckon the UX/UI will actually be easier with that. It eliminates awkward issues like "what team does a user belong to when they first sign up?" "What happens when a user belonging to one team is invited to another?"

On that note, the whole invite functionality needs changing - users would be invited to a team, not an instance.

[rbruggem]

Isn't that just https://cloud.weave.works/instances?

Yes, it will just show more instances depending on which team they belong to.

It eliminates awkward issues like "what team does a user belong to when they first sign up?"

The dropdown (top right) which allows to select instances could also show the team the instance belongs to (if they user belongs to more than one team).

[rbruggem]

It has not been explicitly said:
A team is implicitly created when creating the first instance.
Further new instances are then placed in the same team.

[rbruggem]

High level task breakdown

First iteration - introduce teams

• Create database schema (which includes adding team_id to organizations table)
• Create team row in db on first instance creation (populating trial_* columns), add next new instances to the same team

then

• Backfill organizations.team_id and create teams based on data in organizations/memberships. For Zuora compatibiliy, team.external_id should be == organizations.external_id

then

• Modify code that reads memberships to use both membership and team_memberships tables.
• Create team admin page, with minimal functionality

then

• UI - Move Team page elsewhere.
• Update invite logic to use the new team_membership table only

then

• migrate membership table into team_membership.

State up to this point

• 'team' has been introduced
• billing is still per instance

Second iteration - move trials to teams

• Backfill team.trial_* with data from the newest (to be kind to customers) instances created.
• UI - Move billing page elsewhere
• UI - Billing page to also show usage per instance. The current box shows the sums of all instances.
• UI - Trial box to show data from team.trial_*
• Still upload usage data based on organizations.trial_expires_at and not team.trial_expires_at.

State up to this point:

• 'team' has been introduced
• billing page also shows per instance billing break down
• billing is still per instance (for Zuora there are still many trials)
• billing page shows trial expiry date which is not equivalent to the expiry dates used for actually billing.

Third iteration - move billing to teams

• Store mapping of one-to-one relationship of instance-zuoraChargeID

then

• Migrate instance-ChargeID mapping

then

• Use ChargeID stored in our DB to upload usage.
• Before starting make sure that zuora's account names correspond == organizations.external_id == team.external_id! This should make the migration seamless (it teams have one instance).
• To create an invoice where you have one invoice line for per instance/billing period, (to have breakdown per instance), multiple Charges need to be added to one Subscription: one for each instance. Each of those charges will have a unique ChargeID which needs to be used when uploading usage (see screenshot below).
  • Update usage uploads accordingly
• When creating a zuora account, set Zuora's 'Contract Effective Date' to team.trial_expires_at date.

[rbruggem]

Introduce teams

[rbruggem]

Status update

• The above branch (Teams first iteration #1500 in service repo) is ready for review.
• There is also a service-ui PR: https://github.com/weaveworks/service-ui/pull/1470 which not only needs review but also UX input/changes .
• https://github.com/weaveworks/service-ui/pull/1470 describes the user visible changes.
• The services repo is compatible with the current UI and has to be deployment first.
• The scope document ( https://docs.google.com/document/d/1XmUqw_vI9iwdORGggyiB2X1DKiDEY0bwNoxWAyikYU8/edit#heading=h.8ui31zpgcom ) includes a picture at the bottom, which shows the future desired state in black and, in red, the state with my changes.
• @pidster has seen the changes and has suggested the following:
  • tweak the warning text and put it in the UI element used for warnings
  • default to “new team”, auto-name team “$instance_name Team”
  • check the UI with @bowenli for polish
• There are no admin changes

Some screenshots:

Instances page which includes instance which don't have teams:

Create instance page, allows to enter a team name:

Create instance page, once the user is already part of a team.

Instances pages now includes instances with teams and without teams. A dropdown can be used to filter:

Filtered by team:

The team page includes an additional text field, if the instance is part of a team:

[rade]

A dropdown can be used to filter

IMO that's overkill.

Suggestions:

• when the user belongs to a single team, list the instances as we do currently
• when the user belongs to multiple teams, show the team name inside tiles - it should be less prominent than the instance name - and make that the primary sort key (with instance name being secondary)

[rade]

Create instance page, allows to enter a team name

vs

Create instance page, once the user is already part of a team.

Under what circumstances would a user not be part of a team, and hence see the former?

[bowenli]

1. Yes, I think dropdown is overkill.
2. When we roll this out, I think it makes sense to convert existing users to teams. It doesn't make much sense for the user to be part of a team for some instances and not be part of a team for others.

[bowenli]

[rbruggem]

@bowenli thanks for the suggestions.

Under what circumstances would a user not be part of a team, and hence see the former?

1. The user has no instances.
2. The user has instances with the current no-team model

@rade @pidster are you happy with Bowen's designs?

[pidster]

I suggested the following defaults for id: foo-bar-23, name: "Foo Bar 23", team: "Foo Bar 23 Team", for instances and teams being created for a new user during onboarding.

The wireframes by @bowenli LGTM.

[rndstr]

I suggested the following defaults for id: foo-bar-23, name: "Foo Bar 23", team: "Foo Bar 23 Team", for instances and teams being created for a new user during onboarding.

Related: https://github.com/weaveworks/service-ui/pull/1446

[rbruggem]

https://github.com/weaveworks/service-ui/pull/1470 now looks like:

[rbruggem]

Latest iteration:

Default instance name is now derived from the external id (instead of 'Untitled Cluster').

Clicking 'down arrow' shows:

'Create new team' toggles back to the Textfield

Team page lists all instances belonging to the team

[pidster]

LGTM

[rbruggem]

Status update

• Teams first iteration #1500 is ready to be deployed. Waiting for the conferences to be over to minimize risk.
  The service code supports both old and new UI. The new UI enables teams.
• https://github.com/weaveworks/service-ui/pull/1470 waiting for review.

[leth]

Minor suggestion: The team drop down should probably be titled "Team" not "Team name"

[bowenli]

On the Settings > Team page, how do I see a different team? Is it based on the current instance?

[rbruggem]

On the Settings > Team page, how do I see a different team? Is it based on the current instance?

@bowenli yes