Services/SyncCutoverOptions: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with " ""Order and rack up new machines in a colo (phx or one of our others) in order to scale to 1.1 needs."" Pros: What the system was designed to do. No changes needed to client or...")
 
No edit summary
Line 1: Line 1:
''Prayer''


""Order and rack up new machines in a colo (phx or one of our others) in order to scale to 1.1 needs.""
Pros:


Pros: What the system was designed to do. No changes needed to client or server. Scales up on demand.
* No cost
* No engineering work on client or server
* Might actually be fine


Cons: Additional hardware ask for machines that may not be needed long-term. Hardware lead time. Operational overhead in racking and installing
Cons:


* Will eventually break, depending on how long replacement takes
* May not actually be fine


""Do the work needed to get 1.1 storage running on AWS.""
Need to study growth curves (iops and disk space) to better understand feasibility of this option.


Pros: Infintely scalable on demand. No client changes needed.
''Order and rack up new machines in a colo (phx or one of our others) in order to scale to 1.1 needs.''


Cons: Some throwaway server/deployment work. Technical hurdle of replicating LDAP into the AWS cluster. Legal concerns may require auditing data in the LDAP to make sure it was properly purged before we started using it.
Pros:  


* What the system was designed to do.
* No changes needed to client or server.
* Scales up on demand.


""Port 1.1 to AWS and registration to mysql""
Cons:


Pros: Kills a bunch of LDAP-related technical debt. Dodges ay need to audit LDAP. No client changes. Scalable on demand
* Additional hardware ask for machines that may not be needed long-term
* Hardware lead time
* Operational overhead in racking and installing


Cons: Large amount of throwaway server deployment work, including disruption to the current infrastructure (will need extensive QA).


''Do the work needed to get 1.1 storage running on AWS.''


Pros:


* Infintely scalable on demand.
* No client changes needed.


""Cut over to sync 2.0 on AWS. Leave 1.1 in place""
Cons:
* Some throwaway server/deployment work
* Technical hurdle of replicating LDAP into the AWS cluster
* Legal concerns may require auditing data in the LDAP to make sure it was properly purged before we started using it


Pros: Solves a lot of technical debt. Solves colo issue.


Cons: Identity not viable. Lots of client work. Flag day for upgrade to 2.0 and no backwards compat.
''Port 1.1 to AWS and registration to mysql''


Pros:


""Cut over to sync 2.0 on AWS. Tokenserver supports basic auth.""
* Kills a bunch of LDAP-related technical debt
* Dodges any need to audit LDAP
* No client changes
* Scalable on demand


Pros: No dependency on identity. Nice half-way solution to where we want to be. 2.0 is fully scalable on AWS. No need to replicate into AWS.
Cons:  


Cons: Client work. Flag day (1.1 and 2.0 can't cross operate). Will still need another flag day on identity changeover.
* Large amount of throwaway server deployment work, including disruption to the current infrastructure
* Will need extensive QA for something short-term




""Cut over to sync 2.0 on AWS. Tokenserver supports basic auth. Phoenix colo dual supports 1.1 and 2.0.""


Pros: No dependency on identity. AWS scalability/no replication.


Cons: Client work. Partial flag day for new users (can't also use 1.1) and still doesn't avoid full flag day on identity switch. Can't implement storage format upgrades for clients using both 1.1 and 2.0 (so probably a bunch of client code to dance around that)
''Cut over to sync 2.0 on AWS. Leave 1.1 in place''
 
Pros:
 
* Solves a lot of technical debt
* Solves colo issue
* Gets the one flag day out of the way
 
Cons:
 
* Identity not viable
* Lots of client work
* Flag day for upgrade to 2.0 and no backwards compat
 
This is not technically an option. It's the end goal, but it's clear there's going to be some changes needed before we get here
 
''Cut over to sync 2.0 on AWS. Tokenserver supports basic auth.''
 
Pros:
 
* No dependency on identity
* Nice half-way solution to where we want to be
* 2.0 is fully scalable on AWS
* No need to replicate into AWS
 
Cons:
 
* Client work
* Full flag day (1.1 and 2.0 can't cross operate). Will still need another flag day on identity changeover
 
 
''Cut over to sync 2.0 on AWS. Tokenserver supports basic auth. Phoenix colo dual supports 1.1 and 2.0.''
 
Pros:
 
* No dependency on identity
* AWS scalability/no replication
* Not disruptive to current users
 
Cons:  
* Client work.  
* Partial flag day for new users (can't also use 1.1) and still doesn't avoid full flag day on identity switch.  
* Can't implement storage format upgrades for clients using both 1.1 and 2.0 (so probably a bunch of client code to dance around that)

Revision as of 20:41, 18 January 2013

Prayer

Pros:

  • No cost
  • No engineering work on client or server
  • Might actually be fine

Cons:

  • Will eventually break, depending on how long replacement takes
  • May not actually be fine

Need to study growth curves (iops and disk space) to better understand feasibility of this option.

Order and rack up new machines in a colo (phx or one of our others) in order to scale to 1.1 needs.

Pros:

  • What the system was designed to do.
  • No changes needed to client or server.
  • Scales up on demand.

Cons:

  • Additional hardware ask for machines that may not be needed long-term
  • Hardware lead time
  • Operational overhead in racking and installing


Do the work needed to get 1.1 storage running on AWS.

Pros:

  • Infintely scalable on demand.
  • No client changes needed.

Cons:

  • Some throwaway server/deployment work
  • Technical hurdle of replicating LDAP into the AWS cluster
  • Legal concerns may require auditing data in the LDAP to make sure it was properly purged before we started using it


Port 1.1 to AWS and registration to mysql

Pros:

  • Kills a bunch of LDAP-related technical debt
  • Dodges any need to audit LDAP
  • No client changes
  • Scalable on demand

Cons:

  • Large amount of throwaway server deployment work, including disruption to the current infrastructure
  • Will need extensive QA for something short-term



Cut over to sync 2.0 on AWS. Leave 1.1 in place

Pros:

  • Solves a lot of technical debt
  • Solves colo issue
  • Gets the one flag day out of the way

Cons:

  • Identity not viable
  • Lots of client work
  • Flag day for upgrade to 2.0 and no backwards compat

This is not technically an option. It's the end goal, but it's clear there's going to be some changes needed before we get here

Cut over to sync 2.0 on AWS. Tokenserver supports basic auth.

Pros:

  • No dependency on identity
  • Nice half-way solution to where we want to be
  • 2.0 is fully scalable on AWS
  • No need to replicate into AWS

Cons:

  • Client work
  • Full flag day (1.1 and 2.0 can't cross operate). Will still need another flag day on identity changeover


Cut over to sync 2.0 on AWS. Tokenserver supports basic auth. Phoenix colo dual supports 1.1 and 2.0.

Pros:

  • No dependency on identity
  • AWS scalability/no replication
  • Not disruptive to current users

Cons:

  • Client work.
  • Partial flag day for new users (can't also use 1.1) and still doesn't avoid full flag day on identity switch.
  • Can't implement storage format upgrades for clients using both 1.1 and 2.0 (so probably a bunch of client code to dance around that)