On 10/27/2012 01:27 AM, Chris Wright wrote:
BTW, this is a random side-thought, but a video processing workload would
likely care about GPU feature from a cloud service provider. Point being,
I think this is actually a more sophisticated use case than captured above.
thanks,
-chris
That's a good point, and is presents an opportunity to make a point
about the scope of Winged Monkey, and see if anyone agrees with me..
Given the goal of Winged Monkey to present a simple, attractive,
intuitive UI for non-administrative self-service users to manage the
lifecycle of their applications/instances, I think that low-level
hardware configuration is is good example of the kind of thing that
should be out of scope for Winged Monkey.
We can't have a simple UI, which serves a limited set of use cases well,
unless we draw some pretty hard lines to contain feature creep.
So, in the case of a computational task which would benefit from running
on GPU hardware, the right approach would be for the administrator to
use the capabilities of the underlying provider to build images, and
define deployables, which contain the specification of hardware etc.,
and then to name the deployable in a way that makes its purpose and
capabilities clear enough for the user to select it.
With that in place, Winged Monkey comes in, connects to the provider,
retrieves a list of launchable things, and allows the user to pick.
It was in order to reflect that Winged Monkey will present the
capabilities of the underlying provider that Jeremy added a set of
slides towards the end of the wireframes which show how the UI will
become simpler, with features disappearing, when it is connected to a
simpler provider.
The general rule should be that, if the underlying provider doesn't
support it, Winged Monkey shouldn't show it.
Unless we can get a consensus around that approach, I fear that the
scope of Winged Monkey will expand in all directions, and it will, by
degrees, turn into an attempt to re-implement Conductor.
Angus
