Grid Operations Configuration Management Database. A Repository, Portal and REST style API for managing Grid and Cloud topology objects including; projects, administrative domains, sites, services, service-endpoints, service-groups, downtimes, users, roles and business rules.
If a site declares a large scale outage, services are almost inevitably going to come back in stages yet we can’t easily end the downtime for one service at a time, without originally declaring them all separately.
I can imagine some UI-sugar that removes a service from an existing downtime and puts the service in it's own freshly created downtime that is ending imminetly. But that freshly created downtime would be a different entity in GOCDB from the original downtime and the impact of that isn't clear to me yet. i.e. we would probably want to treat the freshly created downtime as 'scheduled' in GOCDB, but ultimatley - a minute ago that freshly declared downtime didn't exist...
If a site declares a large scale outage, services are almost inevitably going to come back in stages yet we can’t easily end the downtime for one service at a time, without originally declaring them all separately.
I can imagine some UI-sugar that removes a service from an existing downtime and puts the service in it's own freshly created downtime that is ending imminetly. But that freshly created downtime would be a different entity in GOCDB from the original downtime and the impact of that isn't clear to me yet. i.e. we would probably want to treat the freshly created downtime as 'scheduled' in GOCDB, but ultimatley - a minute ago that freshly declared downtime didn't exist...