On 07/24/2011 10:58 AM, Hugh Brock wrote:
On Tue, Jul 19, 2011 at 11:51:19AM -0700, Steven Dake wrote:
> On 07/19/2011 11:11 AM, Hugh Brock wrote:
>> Hello all.
>>
>> With release 0.3.0 about ready to ship it seems like a good time to
>> start talking about features we'd like to see for 0.4.0. I'd like to
>> continue the three-month release cycle we've been on, so that puts our
>> next one around mid-October.
>>
>> Below are some obvious buckets, please feel free to suggest additional
>> features large or small.
>>
>> Finally, note I'm not making any claim that the list below is
>> achievable in the timeframe we're talking about (although I would hope
>> it's not that far from what is achievable). I'm more thinking in terms
>> of what would make our 0.4.0 release seem like a coherent whole, and
>> make the largest number of upstream users interested and happy.
>>
>> I'll start with Conductor features:
> <
>
> <snip>
>
>> * Status reporting
>>
>> * We should reliably display the status of a running instance and
>> its uptime
>>
>> * We should start thinking about how we will handle the richer data
>> about instance health that we will get once Matahari is in place
>>
>> * Users should be able to view an audit trail of events for an
>> instance or a set of instances
>>
>> * Users should be able to export those events
>
> This would be a good place for pacemaker-cloud integration. Currently
> we generate QMF events when state change events occur.
>
> Here is an example of a 3 assembly deployable where assembly 2 is
> terminated (and then restarted by pacemaker-cloud):
>
> system start:
>
> Event: {'reason': 'All good', 'assembly':
'assy1-F14', 'state':
> 'running', 'deployable': 'dep1-F14'}
> Event: {'reason': 'All good', 'assembly':
'assy2-F14', 'state':
> 'running', 'deployable': 'dep1-F14'}
> Event: {'reason': 'All good', 'assembly':
'assy3-F14', 'state':
> 'running', 'deployable': 'dep1-F14'}
>
> At this point all assemblies are started in the deployable dep1-F14
>
> Then we terminate an assembly via virtual machine manager GUI:
>
> Event: {'reason': 'Not reachable', 'assembly':
'assy2-F14', 'state':
> 'failed', 'deployable': 'dep1-F14'}
>
> Then it is restarted by pacemaker-cloud (and active):
>
> Event: {'reason': 'All good', 'assembly':
'assy2-F14', 'state':
> 'running', 'deployable': 'dep1-F14'}
>
> These events all occur as a result of monitoring matahari of all
> assemblies+deployables.
Yes -- so we need to get this stuff into the event log that we display
to the user, at a minimum.
When do you expect you'll be ready to stand this thing up and have it
talk to Conductor? Do you have any sense of what sort of API we'll
need to provide you to make the integration work?
We will be wrapped up with most stand-alone development this week. For
integration, we need to have discussion and then agreement on the topic
of the API/(s) you mentioned.
When the integration will be complete is hard to predict. There are
many unknowns that require definition. I'll kick the API discussion off
next week when we wrap up with our Fedora 16 release. This should
provide us with a better understanding of integration tasks required and
their associated schedules.
Regards
-steve