Ideas for Kubecon 2016 user's questionnaire

[bryk]

We will send out a questionnaire to Kubecon attendees and our users after the talk me and @romlein are doing on Kubecon.

We did this last year with @cheld and @dodwyer and it was really successful. We received like 300 responses and the results infographics is here.

Do you have any ideas what should we ask the audience and our users? We need a set of questions that'd clarify our roadmaps and validate product direction.

CCing all that might be interested: @cheld @romlein @rf232 @IanLewis @digitalfishpond @bgrant0607 @pwittrock

[arieljatib]

Going with the same questions as last year is great. It will be interesting to compare and contrast results a year later.

Regarding,

We need a set of questions that'd clarify our roadmaps and validate product direction.

We should share the work we've done on user stories in SIG-UI : Target User Types and Use Cases and encourage others to participate / vote. This could also help promote the broader participation @IanLewis and the group have discussed.

[ianlewis]

This is a completely separate idea, but could the dashboard collect usage metrics if users opt in?

[ianlewis]

I like the idea of using the same questions as last year and see how things have changed.

[cheld]

@IanLewis in general this would be helpful. Sharing raw data is probably difficult because even statistical data might contain senseful data.

@kenan435 any thoughts on using spartakus with dashboard?

[cheld]

CC @fwalker

[ianlewis]

I looked at spartakus but it looked like it wasn't sending data with the granularity that we might want with the UI.

Would be interesting if dashboard was able to interoperate but I think it may go against the spirit of spartakus which was to just stick a pod in the cluster and have it relay info obtained from the Kubernetes API.

[bryk]

@IanLewis

This is a completely separate idea, but could the dashboard collect usage metrics if users opt in?

Can you spawn an issue about this?

[rf232]

This is actualy the first time I see this infographic, looks nice :)

It is also interesting too see that the 'readonly' operations of monitoring and looking at the state are coming up as the most important ones. My most important question is how those values change dependant on which of the three user types (as defined in the document @Ariel linked to) you are. So I think indeed the same questions, but try to get some correlation in answers out of the interview between demographic and feature importance.

And if we are going at it, this same correlation research compared to cluster size might be interesting too.

[bgrant0607]

@rf232 FWIW, inside Google, our 2 main UIs for Borg are both readonly. Our users want operational dashboards, which, honestly, is the core strength of the UI -- visualization.

They control their workloads through configuration files checked into source control, with the ability to review and approve changes, trigger tests via CI, rollback, view change history, etc.

Direct use of CLI or API is also more amenable to automation, which ~all teams need to do pretty quickly -- as soon as you have to do something more than once, basically.

Even canned examples are easier to repeat via CLI. In my view, launching off-the-shelf workloads is, as well, since I'd want to (a) fork the package spec and (b) commit the parameter values to source control, also.

Here's a summary of my view of part of the workload-management space in K8s: https://docs.google.com/document/d/1S3l2F40LCwFKg6WG0srR6056IiZJBwDmDvzHWRffTWk/edit#

Please join kubernetes-sig-ui@googlegroups.com or kubernetes-dev@googlegroups.com to view.

As I see it, the main advantage of a UI for configuration is discoverability of features, and perhaps wizard-like guidance. Discoverability in the CLI could be addressed using textual templates with comments. A wizard could be built using a text-based interface, but a UI would be a better experience in that case, perhaps with an option to export the generated configuration. The primary use case would be learning how to use the system, as opposed to really using it, especially in production.

cc @pwittrock

[bgrant0607]

And, the obligatory reference to #21. :-)

[bgrant0607]

In case it's not obvious:

And why the heavy emphasis on repeatability and configuration? I do development on a VM I created via a UI. Why is K8s different?

• Immutability. For my development VM, I configured almost nothing and then just ssh'd to it and futzed with its image interactively, to install packages, etc. Container images are typically built from Dockerfiles (or other configurable/scripted processes) and have parameters overridden by configuration.
• Ephemerality. I've been using that VM for 2 years. I update the image occasionally, but I only had to update its configuration once, to increase the amount of memory. Containers typically have lifetimes that are measured in days, hours, even minutes.
• Scalability. I suppose I could clone my development VM to scale my build capacity, but them keeping them up to date and in sync would be a nightmare. OTOH, we want to be able to scale cloud-native apps painlessly.
• Availability. Anyone running production applications is going to want to run more than one instance in order to avoid a single point of failure.
• Automation. K8s is all about automating operations and management.

These can apply VMs, too, if you manage them like Netflix, but is far more common with containers.

[danielromlein]

Those comments are super helpful @bgrant0607 – thanks!

@rf232 I like your idea about correlating user types with what UI functionality is most important to them.