[Openstack-operators] What would you like in Pike?

Piet Kruithof pkruithofjr at gmail.com
Tue Jan 17 17:47:41 UTC 2017

Sorry for the late reply, but wanted to add a few things.

OpenStack UX did suggest to the foundation that the community needs a
second survey that focuses exclusively on operators.  The rationale was
that the user survey is primarily focused on marketing data and there isn't
really a ton of space for additional questions that focuses exclusively on
operators. We also recommended a second survey called a MaxDiff study that
enabled operators to identify areas of improvement and also rate them in
order of importance including distance.

There is also an etherpad that asked operators three priorities for


It was distributed about a year ago, so I'm not sure how much of it was
relevant.  The list does include responses from folks at TWC, Walmart,
Pacific Northwest Labs, BestBuy, Comcast, NTTi3 and the US government. It
might be a good place for the group to add their own improvements as well
as "+" other peoples suggestions.

There is also a list of studies that have been conducted with operators on
behalf of the community. The study included quotas, deployment and
information needs. Note that the information needs study extended beyond
docs to things like the need to easily google solutions and the need for

Hope this is helpful.


The goal of this presentation is to provide an overview of research that
was conducted on behalf of the OpenStack community.  All of the studies
conducted on behalf of the OpenStack community were included in this

Why this research matters:
Consistency across projects has been identified as an issue in the user

Study design:
This usability study, conducted at the OpenStack Austin Summit, observed 10
operators as they attempted to perform standard tasks in the OpenStack


Why this research matters:
The Searchlight plug-in for Horizon aims to provide a consistent search API
across OpenStack resources. To validate its suitability and ease of use, we
evaluated it with cloud operators who use Horizon in their role.

Study design:
Five operators performed tasks that explored Searchlight’s filters,
full-text capability, and multi-term search.


Why this research matters:
The study was initiated following operator feedback identifying quotas as a
challenge to manage at scale.

Study design:
One-on-one interviews with cloud operators sought to understand their
methods for managing quotas at production scale.


Why this research matters:
Documentation has been consistently identified as an issue by operators
during the user survey.  However, we wanted to understand the entire
workflow associated with identifying and consuming information to resolve
issues associated with operating production clouds.

Study design:
This research consisted of interviews with seven cloud operators from
different industries with varying levels of experience to determine how
they find solutions to problems that arise.


Why this research matters:
Deployment has been consistently identified as an issue by operators during
the user survey and impacts both adoption and operations of OpenStack.  We
wanted to do a deep dive with operators to identify the specific issues
impacting deployment.

Study design:
A series of 1:1 interviews that included included discussions around
organizations, tools, workflows and pain points associated with deploying


Why this research matters:
Consistency across projects has been identified as an issue in the user

Study design:
This usability study, conducted at the OpenStack Austin Summit, observed 10
operators as they attempted to perform standard tasks in the OpenStack


On Tue, Jan 17, 2017 at 10:07 AM, Jonathan Proulx <jon at csail.mit.edu> wrote:

> What Tim said :)
> my ordering:
> 1) Preemptable Instances -- this would be huge and life changing I'd
>    give up any other improvements to get this.
> 2) Deeper utilization of nested projects -- mostly we find ways to
>    mange with out this but it would be great to have.
>    A) to allow research groups (our internal fiscal/administrative
>    divisions) to sub divide quota allocations accordinf to their own
>    priorities on a self serve basis (provided proper RBAC configs)
>    B) to answer show back questions more easily.  Currently with flat
>    projects individual research groups have multiple openstack
>    projects, by convention we mange to usually be able to aggregaet
>    them in reporting, but deing able to show susage by a parent and
>    all it 's childeren woudl be very useful
> 3) Quota improvements -- this is important but we've learned to deal
>    with it
> -Jon
> On Sat, Jan 14, 2017 at 10:10:40AM +0000, Tim Bell wrote:
> :There are a couple of items which have not been able to make it to the
> top priority for recent releases which would greatly simplify our day to
> day work with the users and make the cloud more flexible. The background
> use cases are described in https://openstack-in-
> production.blogspot.fr/2016/04/resource-management-at-cern.html
> :
> :
> :-          Quota management improvements
> :
> :o    Manual interventions are often required to sync the current usage
> with the OpenStack view
> :
> :o    Nested projects are now in Keystone but is limited support in other
> projects for the end user benefit, such as delegation of quota for
> sub-projects
> :
> :-          Nova pre-emptible instances  (https://review.openstack.org/
> #/c/104883/) to give spot market functionality
> :
> :o    We want to run our cloud at near 100% utilisation but this requires
> rapid ejection of lower priority VMs
> :
> :That having been said, I also fully support key priorities currently
> being worked on such as cells v2 and placement.
> :
> :Tim
> :
> :From: Melvin Hillsman <mrhillsman at gmail.com>
> :Date: Friday, 13 January 2017 at 02:30
> :To: openstack-operators <openstack-operators at lists.openstack.org>
> :Subject: [Openstack-operators] What would you like in Pike?
> :
> :Hey everyone,
> :
> :I am hoping to get a dialogue started to gain some insight around things
> Operators, Application Developers, and End Users would like to see happen
> in Pike. If you had a dedicated environment, dedicated team, and freedom to
> choose how you deployed, new features, older features, enhancements, etc,
> and were not required to deal with customer/client tickets, calls, and
> maintenances, could keep a good feedback loop between your team and the
> upstream community of any project, what would like to make happen or work
> on hoping the next release of OpenStack had/included/changed/enhanced/
> removed…?
> :
> :Kind regards,
> :--
> :Melvin Hillsman
> :
> :Ops Technical Lead
> :OpenStack Innovation Center
> :
> :
> :
> :mrhillsman at gmail.com<mailto:mrhillsman at gmail.com>
> :phone: (210) 312-1267
> :mobile: (210) 413-1659
> :Learner | Ideation | Belief | Responsibility | Command
> :
> :http://osic.org
> :
> :
> :_______________________________________________
> :OpenStack-operators mailing list
> :OpenStack-operators at lists.openstack.org
> :http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> --
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Pieter C Kruithof Jr, MS, CPE
PTL, OpenStack UX project


512 576-2844

This email message and any attachments hereto is intended for use only by
the addressee(s) named herein. If you have received this email in error,
please immediately notify the sender and permanently delete the original
and any copy of this message and its attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170117/905661b6/attachment.html>

More information about the OpenStack-operators mailing list