Hi Tim, We did wonder in last week's meeting whether quota management and nested project support (particularly which flows are most important) would be a good session for the Boston Forum...? Would you be willing to lead such a discussion?
Cheers, On 19 January 2017 at 19:59, Tim Bell <tim.b...@cern.ch> wrote: > > On 18 Jan 2017, at 23:20, Matt Jarvis <m...@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. > > > For the quota management, I think the first discussions were in the Hong > Kong summit around the Boson project and this has moved backwards and > forwards between services, libraries and improving the code. While the user > need is relatively simple to state, these are not simple problems to solve > so it is often difficult for the items to get to the priority lists. > > One of the difficulties we have found is that we could get staff for a > project such as quota management for a short period (e.g. 1 year). However, > from the initial specification to code acceptance is often an extended > period so these sort of changes can get stalled but the people contributing > need to show results for their work (such as a thesis). > > From the scientific working group discussions, the quota and nesting > discussions have come up regularly so the requirements are still there. > > Tim > > On Wed, Jan 18, 2017 at 10:06 PM, Sam Morrison <sorri...@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 <mrhills...@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 <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_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 <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/opensta >>>>> ck-operators >>>>> >>>>> >>>>> -- >>>>> >>>>> _______________________________________________ >>>>> OpenStack-operators mailing list >>>>> OpenStack-operators@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@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 >> >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > -- Cheers, ~Blairo
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
