Skip to content

Commit

Permalink
Reformatted code blocks again
Browse files Browse the repository at this point in the history
  • Loading branch information
Digant C Kasundra committed May 20, 2015
1 parent b4d6999 commit f8ff3ea
Showing 1 changed file with 152 additions and 124 deletions.
276 changes: 152 additions & 124 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -14,12 +14,14 @@ As journal entries, events provide an audit trail and can potentially be used to

Each event must be of a predefined event type. An event type consists of a category and state, the combination of which provides meaningful grouping and definition:

ID CATEGORY STATE
[1] system-reboot required
[2] system-reboot completed
[3] system-maintenance required
[4] system-maintenance ready
[5] system-maintenance completed
```
ID CATEGORY STATE
[1] system-reboot required
[2] system-reboot completed
[3] system-maintenance required
[4] system-maintenance ready
[5] system-maintenance completed
```

Event types are often written simply as `category-state`, such as `system-reboot-required`.

Expand All @@ -35,27 +37,35 @@ Labors are usually referred to by the event which triggered its creation, so a `
### Basics ###
The fates define how labors are created and completed. A typical fate will specify which event type will result in the creation of a labor for the host, and which event type will close labors for a host.

[1] system-reboot-required => system-reboot-completed
```
[1] system-reboot-required => system-reboot-completed
```

### Chained Fates ###
An `intermediate` flag in the definition of a fate indicates if the fate only applies to existing labors. This allows fates to be chained together to essentially create a workflow engine.

For example:
[1] system-maintenance-required => system-maintenance-ready
[2] system-maintenance-ready => system-maintenance-completed
```
[1] system-maintenance-required => system-maintenance-ready
[2] system-maintenance-ready => system-maintenance-completed
```

(with the second fate being flagged as an intermediate) would essentially mean:

system-maintenance-required => system-maintenance-ready => system-maintenance-completed
```
system-maintenance-required => system-maintenance-ready => system-maintenance-completed
```

In this example, an event of type `system-maintenance-ready` only creates a labor if an existing labor created by an event of type `system-maintenance-required` was present.

### Choose Your Own Adventure ###

Fates can allow multiple ways to resolve a labor.

[1] puppet-restart-required => puppet-restart-completed
[2] puppet-restart-required => system-restart-completed
```
[1] puppet-restart-required => puppet-restart-completed
[2] puppet-restart-required => system-restart-completed
```

In this example, a labor created by the event `puppet-restart-required` can be completed by either a `puppet-restart-completed` event, or a `system-restart-completed` event.

Expand Down Expand Up @@ -91,14 +101,18 @@ explicitly set using the limit parameter in the URL. The limit value,
whether specified or applied by default, will be reflected in the data
returned.

`/api/v1/host/[hostname]/events/?limit=50`
```
/api/v1/host/[hostname]/events/?limit=50
```

## Paging ##

In conjuction with limits, a particular page of data can be requested with
the page parameter.

`/api/v1/host/[hostname]/events/?limit=20&page=2`
```
/api/v1/host/[hostname]/events/?limit=20&page=2
```

## Expansion ##

Expand All @@ -108,81 +122,91 @@ parameter.

Multiple expansion parameters can be used.

`/api/v1/quests/[questid]/?expand=labors&expand=events`
```
/api/v1/quests/[questid]/?expand=labors&expand=events
```

## GETs ##

### Hosts ###

To get host data, use `/api/v1/hosts/[hostname]/`

{
id: int,
hostname: string,
limit: int,
page: int,
lastEvent: timestamp,
events: [],
labors: [],
quests: [],
}
```
{
id: int,
hostname: string,
limit: int,
page: int,
lastEvent: timestamp,
events: [],
labors: [],
quests: [],
}
```

To get all hosts, use `/api/v1/hosts/` (with an appropriate limit and page)

{
limit: int,
page: int,
totalHosts: int,
hosts: [],
}
```
{
limit: int,
page: int,
totalHosts: int,
hosts: [],
}
```

### Event Types ###

To get event types, use `/api/v1/eventtypes/`

{
limit: int,
page: int,
totalEventTypes: int,
eventTypes: [
{
id: int,
category: string,
state: string,
description: string,
},
...
],
}
```
{
limit: int,
page: int,
totalEventTypes: int,
eventTypes: [
{
id: int,
category: string,
state: string,
description: string,
},
...
],
}
```

### Events ###

To get events, use `/api/v1/events/`

{
limit: int,
page: int,
totalEvents: int,
events: [
{
```
{
limit: int,
page: int,
totalEvents: int,
events: [
{
id: int,
host: {
id: int,
host: {
id: int,
hostname: string,
},
timestamp: timestamp,
user: string,
eventType: {
id: int,
category: string,
state: string,
description: string,
},
note: string,
hostname: string,
},
timestamp: timestamp,
user: string,
eventType: {
id: int,
category: string,
state: string,
description: string,
},
...
],
}
note: string,
},
...
],
}
```

Events can also be expanded in other queries, like host queries. Never
expand both host and event in a query or you will trigger infinite
Expand All @@ -194,76 +218,80 @@ To get a particular event, use `/api/v1/events/[eventId]`.

To get fates, use `/api/v1/fates`

{
limit: int,
page: int,
totalFates: int,
fates: [
{
```
{
limit: int,
page: int,
totalFates: int,
fates: [
{
id: int,
creationEventType: {
id: int,
creationEventType: {
id: int,
category: string,
state: string,
description: string,
},
completionEventType: {
id: int,
category: string,
state: string,
description: string,
},
intermediate: true|false,
category: string,
state: string,
description: string,
},
completionEventType: {
id: int,
category: string,
state: string,
description: string,
},
...
],
}
intermediate: true|false,
description: string,
},
...
],
}
```

To get a particular fate, use `/api/v1/fates/[fateId]`.

### Labors ###

To get labors, use `/api/v1/labors/`

{
limit: int,
page: int,
totalFates: int,
labors: [
{
```
{
limit: int,
page: int,
totalFates: int,
labors: [
{
id: int,
quest: {
id: int,
quest: {
id: int,
embarkTime: timestamp,
completionTime: timestamp,
creator: string,
description: string,
},
host: {
id: int,
hostname: string,
},
creationTime: timestamp,
ackTime: timestamp,
ackUser: string,
embarkTime: timestamp,
completionTime: timestamp,
creationEvent: {
id: int,
timestamp: timestamp,
user: string,
note: string,
},
completionEvent: {
id: int,
timestamp: timestamp,
user: string,
note: string,
},
creator: string,
description: string,
},
host: {
id: int,
hostname: string,
},
...
],
}
creationTime: timestamp,
ackTime: timestamp,
ackUser: string,
completionTime: timestamp,
creationEvent: {
id: int,
timestamp: timestamp,
user: string,
note: string,
},
completionEvent: {
id: int,
timestamp: timestamp,
user: string,
note: string,
},
},
...
],
}
```

To get a particular labor, use `/api/v1/labors/[laborId]`.

Expand Down

0 comments on commit f8ff3ea

Please sign in to comment.