Some thoughts...
Simply returning TRY_AGAIN to APIs and keeping alive such a headless cluster
would not yield any desired result. All events (not trigerred by APIs) and
faults which typically involve decision making by directors will remain un
processed during this period of 'loss of service' and could also lead to
permanent loss of service for the applications.
If considering VMs as unreliable deployments is a valid usecase then, the
probability that two controllers go down at the same time in cloud deployments
would be the same that all nodes of the cluster go down. If this is how much
unplanned downtime we design for, we are probably talking about more such
frequent occurrences of downtime throughout the year. So, i have my doubts
about the validitiy of this usecase which in other words claims that cloud
deployments are not robust!
When we all seem to agree that having multiple standbys (or spares) and
electing a new active 'immediately' when the last ACTIVE goes down is the way
to go, then perhaps we should consider investing our time on #1170 and #439.
#1170 would breakdown into couple of more tickets on other services.
Talking about cloud deployments, we should also focus on some AMF enhancements,
one of which is the need to support autoadjust. Read it as 'affinity' in cloud
terms, i.e. affinity for assigning workloads to a given node once it comes back
again and is ready...
More to follow...
---
** [tickets:#1132] opensaf shall support temporary unavailbility of both
controllers**
**Status:** unassigned
**Milestone:** 4.6.FC
**Created:** Tue Sep 23, 2014 01:51 PM UTC by Hans Feldt
**Last Updated:** Wed Oct 15, 2014 08:02 AM UTC
**Owner:** nobody
The opensaf cluster shall survive that both system controllers are temporarily
down (no cluster reboot as today)
After the system controllers recover, IMM and AMF state shall be as before the
controllers got unavailable.
Use case: opensaf cloud deployment
To be refined a lot...
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
