Open Stack

Hi Sam,

I've been trying to wrangle folks into discussions to see how we can
improve policy as a whole across OpenStack [0] [1]. So far, we've had some
involvement from a couple operators, but more feedback would be even better.

My goal is to try and generate a bunch of discussion prior to the PTG so
that in Atlanta we can start painting a picture of what policy/RBAC in
OpenStack needs to be. I think once that is clearly documented it will be
easier for us to break it into actionable goals that the projects can
pursue as a group.

Feel free to come find me (lbragstad) in #openstack-keystone. I'd be happy
to make some time to get specific feedback.

[0]
http://lists.openstack.org/pipermail/openstack-dev/2017-January/109967.html
[1] http://eavesdrop.openstack.org/#Keystone_Policy_Meeting


On Wed, Jan 18, 2017 at 4:20 PM, Matt Jarvis <matt at mattjarvis.org.uk> wrote:

> I think one of the problems we're seeing now is that a lot of operators
> have actually already scratched some of these missing functionality itches
> like quota management and project nesting by handling those scenarios in
> external management systems. I know we certainly did at DataCentred. That
> probably means these things don't surface enough to upstream as
> requirements, whereas for new users who aren't necessarily in the loop with
> community communication they may well be creating friction to adoption.
>
> On Wed, Jan 18, 2017 at 10:06 PM, Sam Morrison <sorrison at gmail.com> wrote:
>
>> I would love it if all the projects policy.json was actually usable. Too
>> many times the policy.json isn’t the only place where authN happens with
>> lots of hard coded is_admin etc.
>>
>> Just the ability to to have a certain role to a certain thing would be
>> amazing. It makes it really hard to have read only users to generate
>> reports with that we can show our funders how much people use our openstack
>> cloud.
>>
>> Cheers,
>> Sam
>> (non-enterprise)
>>
>>
>>
>> On 18 Jan 2017, at 6:10 am, Melvin Hillsman <mrhillsman at gmail.com> wrote:
>>
>> 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 <matt at 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 <pkruithofjr at 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_w1Ea
>>>> QcZQ1Bq2YWeB-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 <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-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 <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/opensta
>>>>> ck-operators
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-operators mailing list
>>>>> OpenStack-operators at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstac
>>>>> k-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 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
>>>
>>>
>>
>>
>> --
>> Kind regards,
>>
>> Melvin Hillsman
>> Ops Technical Lead
>> OpenStack Innovation Center
>>
>> mrhillsman at gmail.com
>> phone: (210) 312-1267
>> mobile: (210) 413-1659
>> http://osic.org
>>
>> Learner | Ideation | Belief | Responsibility | Command
>> _______________________________________________
>> 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
>>
>>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170118/a7b36956/attachment.html>