[openstack-dev] [TripleO] UI Wireframes - close to implementation start

Jaromir Coufal jcoufal at redhat.com
Fri Dec 6 12:24:29 UTC 2013


On 2013/06/12 00:00, James Slagle wrote:
> Jarda,
>
> This stuff looks really great. I like the flow quite a bit.  One thing
> that stuck out to me though is that I didn't see anything around
> troubleshooting a Deployment.  Since stuff does occassionally go wrong
> :), it might be nice to mock up how troubleshooting that might look.
>
> I think we already have the logs in Horizon, but bubbling that up to
> the user on the deployment screen might be nice.  Or, perhaps links
> back to the logs if something failed.
>
> In the pdf for deployment[1], slide 13, there's shown a node that
> failed.  But, I don't see much there in terms of getting at how/why it
> failed.
>
> I know I'm probably thinking way far out here :), but there was some
> good discussion at the summit on Heat making it easier to debug stack
> failures, adding retries, etc.  I know that's stuff still early, but
> it might make sense to think about hooking into that once available.
> [2].  There was also an idea of adopting a stack [3].  This might be a
> way for folks who already have a deployment to bring it under the
> control of Tuskar so to speak.
>
> Anyway, it doesn't look like anything in the mockups would make it
> difficult to hook into these new API's once avaiable, but I just
> thought I would mention them.  Thanks!
>
> [1] http://people.redhat.com/~jcoufal/openstack/tripleo/2013-12-03_tripleo-ui_03-deployment.pdf
> [2] https://blueprints.launchpad.net/heat/+spec/troubleshooting-low-level-control
> [3] https://blueprints.launchpad.net/heat/+spec/adopt-stack

James,

this is great note and very important part what we need to focus. I 
completely agree with you.

At the moment I tried to get something up for designing and deploying a 
cloud - to make sure that this is good direction to go. And that we can 
actually start delivering.

Most of the pages what you see at the moment are overview pages - their 
purpose is to show general information and to help to notice that 
'something' went wrong.

To figure out what exactly went wrong, I expect to get into bigger 
details a bit later (through notifications, logs, node detail pages).

We definitely should keep above listed blueprints in our minds to think 
about how to hook them for our needs - they look very useful. I will 
keep them also in mind when designing troubleshooting in more details.

Thanks a lot this is great help
-- Jarda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131206/be85ea73/attachment.html>


More information about the OpenStack-dev mailing list