Well said, as a consequence of this thread being on the mailing list, I hope that we can get *all* operators, end-users, and app-developers to respond. If you are aware of folks who do not fall under the "enterprise" label please encourage them directly to respond; I would encourage everyone to do the same.
On Tue, Jan 17, 2017 at 11:52 AM, Silence Dogood <m...@nycresistor.com> wrote: > I can see a huge problem with your contributing operators... all of them > are enterprise. > > enterprise needs are radically different from small to medium deployers > who openstack has traditionally failed to work well for. > > On Tue, Jan 17, 2017 at 12:47 PM, Piet Kruithof <pkruitho...@gmail.com> > wrote: > >> 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 >> OpenStack: >> >> https://etherpad.openstack.org/p/mitaka-openstackux-enterprise-goals >> >> 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 >> SMEs. >> >> Hope this is helpful. >> >> Piet >> >> ___ >> OPENSTACK USER EXPERIENCE STATUS >> 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 >> presentation. >> >> Why this research matters: >> Consistency across projects has been identified as an issue in the user >> survey. >> >> Study design: >> This usability study, conducted at the OpenStack Austin Summit, observed >> 10 operators as they attempted to perform standard tasks in the OpenStack >> client. >> >> https://docs.google.com/presentation/d/1hZYCOADJ1gXiFHT1ahwv >> 8-tDIQCSingu7zqSMbKFZ_Y/edit#slide=id.p >> >> >> >> ___ >> USER RESEARCH RESULTS: SEARCHLIGHT/HORIZON INTEGRATION >> 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. >> >> https://docs.google.com/presentation/d/1TfF2sm98Iha-bNwBJrCT >> Cp6k49zde1Z8I9Qthx1moIM/edit?usp=sharing >> >> >> >> ___ >> CLOUD OPERATOR INTERVIEWS: QUOTA MANAGEMENT AT PRODUCTION SCALE >> 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. >> >> https://docs.google.com/presentation/d/1J6-8MwUGGOwy6-A_ >> w1EaQcZQ1Bq2YWeB-kw4vCFxbwM/edit >> >> >> >> ___ >> CLOUD OPERATOR INTERVIEWS: INFORMATION NEEDS >> 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. >> >> https://docs.google.com/presentation/d/1LKxQx4Or4qOBwPQbt4jA >> ZncGCLlk_Ez8ZRB_bGp19JU/edit?usp=sharing >> >> >> >> ___ >> OPERATOR INTERVIEWS: DEPLOYMENT AT PRODUCTION >> 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 >> OpenStack. >> >> https://docs.google.com/presentation/d/14UerMR4HrXKP_0NE_C-W >> J16YQFzgetL1Tmym9FNFzpY/edit?usp=sharing >> >> >> ___ >> OPERATOR USABILITY: OPENSTACKCLIENT >> Why this research matters: >> Consistency across projects has been identified as an issue in the user >> survey. >> >> Study design: >> This usability study, conducted at the OpenStack Austin Summit, observed >> 10 operators as they attempted to perform standard tasks in the OpenStack >> client. >> >> https://docs.google.com/presentation/d/1cBUJuLL9s7JQppVlDBBJ >> MrNNpfqwdkHyfZFuwY6lNgM/edit#slide=id.g1a8df2eaf2_1_0 >> >> >> >> >> >> >> >> >> >> >> On Tue, Jan 17, 2017 at 10:07 AM, Jonathan Proulx <j...@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-productio >>> n.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 <mrhills...@gmail.com> >>> :Date: Friday, 13 January 2017 at 02:30 >>> :To: openstack-operators <openstack-operators@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 >>> : >>> : >>> : >>> :mrhills...@gmail.com<mailto:mrhills...@gmail.com> >>> :phone: (210) 312-1267 >>> :mobile: (210) 413-1659 >>> :Learner | Ideation | Belief | Responsibility | Command >>> : >>> :http://osic.org >>> : >>> : >>> >>> :_______________________________________________ >>> :OpenStack-operators mailing list >>> :OpenStack-operators@lists.openstack.org >>> :http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>> >>> >>> -- >>> >>> _______________________________________________ >>> OpenStack-operators mailing list >>> OpenStack-operators@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >>> >> >> >> >> -- >> Pieter C Kruithof Jr, MS, CPE >> PTL, OpenStack UX project >> >> http://www.linkedin.com/in/pkruithofjr >> >> 512 576-2844 <(512)%20576-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. >> >> _______________________________________________ >> OpenStack-operators mailing list >> OpenStack-operators@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >> >> > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > -- Kind regards, Melvin Hillsman Ops Technical Lead OpenStack Innovation Center mrhills...@gmail.com phone: (210) 312-1267 mobile: (210) 413-1659 http://osic.org Learner | Ideation | Belief | Responsibility | Command
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators