Re: [Openstack-operators] What would you like in Pike?
Blair, Sure. I’d also be happy for a second volunteer to share it with so that we get a rounded perspective, it is important that we don’t get too influenced by one organisation’s use cases. Tim From: Blair Bethwaite Date: Thursday, 19 January 2017 at 20:24 To: Tim Bell Cc: "m...@mattjarvis.org.uk" , openstack-operators Subject: Re: [Openstack-operators] What would you like in Pike? 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 mailto:tim.b...@cern.ch>> wrote: On 18 Jan 2017, at 23:20, Matt Jarvis mailto: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 mailto: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 mailto: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 mailto: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 mailto: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 Op
[Openstack-operators] OsOps Reboot
Good day everyone, As operators we would like to reboot the efforts started around OsOps. Initial things that may make sense to work towards are starting back meetings, standardizing the repos (like having a lib or common folder, READMEs include release(s) tool works with, etc), increasing feedback loop from operators in general, actionable work items, identifying teams/people with resources for continuous testing/feedback, etc. We have got to a great place so let's increase the momentum and maximize all the work that has been done for OsOps so far. Please visit the following link [ https://goo.gl/forms/eSvmMYGUgRK901533 ] to vote on day of the week and time (UTC) you would like to have OsOps meeting. And also visit this etherpad [ https://etherpad.openstack.org/p/osops-meeting ] to help shape the initial and ongoing agenda items. Really appreciate you taking time to read through this email and looking forward to all the great things to come. Also we started an etherpad for brainstorming around how OsOps could/would function; very rough draft/outline/ideas right now again please provide feedback: https://etherpad.openstack.org/p/osops-project-future -- 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
Re: [Openstack-operators] What would you like in Pike?
> On Jan 18, 2017, at 5:20 PM, Matt Jarvis 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. Agree, there are certain elements associated with the holistic lifecycle and feature requirements that are being solved for externally. Could we add this type of content to OSOps? I know it was meant for sharing best practices, tools, etc. but I am curious about how many people are contributing there. Your other message about newcomers made me think about it. > 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 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 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 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 > 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/1hZYCOADJ1gXiFHT1ahwv8-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 per
[Openstack-operators] Ping
-- Pieter C Kruithof Jr, MS, CPE PTL, OpenStack UX project http://www.linkedin.com/in/pkruithofjr 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. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [Large Deployments Team] won't be able to make a meeting tonight
I have some conflicts. Would team members be interested in a make up at the same time next week? Sent from my iPhone ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] (dis)Continuation of Neutron VPNaaS
On 19 January 2017 at 13:41, Bruno L wrote: > Hi, > > November last year the Neutron team has announced that VPN as a Service > will be no longer part of Neutron[1]. > > We run a public cloud based in New Zealand called Catalyst Cloud[2]. Our > customers find the VPN service extremely useful to integrate their cloud > tenant's with on-premise infrastructure or even other clouds. We have > almost one hundred VPNs that were established by customers using it. > > While customers could run a compute instance with something like VyOS, > they are used to the convenience of having a service managed by us that is > easy to consume via the APIs or dashboard. It would be a step back for us > to discontinue VPNaaS. > > As a result, we are interested in picking up the development of VPNaaS and > keeping it alive. If like us, you are an organisation that sees value in > VPNaaS, please get in touch with me to discuss how we can collaborate on it. > > As a first step, we would like to ensure that it continue to pass CI and > it is free of major bugs. Then, we would like to address some of the points > raised in the VPNaaS scorecard[3] to bring it up to standard with other > Neutron services. We don't envisage introducing new features during this > period, but rather focus on stability and maturity. > > Could someone from the Neutron team please help us with the questions > below? > 1) What would be the process to transfer ownership of the project? > Hi Bruno, That's great to hear. If you have dev resources who are ready to jump in Gerrit, please point me to their IRCs and Gerrit accounts and I am happy to engage with them directly. Yamamoto and I have still core rights on the repo and work on pushing fixes on an occasional basis. Once your devs feel more confident, we can definitely talk about adding them to the neutron-vpnaas core team. > 2) Until we bring it up to standard, would we need to maintain it as a > separate project, or as part of Neutron? > My suggestion is to focus on the technical aspect of things before worrying about the governance change. Those typically can happen only in certain time windows of the release and with the Ocata release approaching feature freeze, we definitely need to postpone the governance discussion until Pike opens up. Thanks, Armando (irc:armax) > Cheers, > Bruno > > [1] http://lists.openstack.org/pipermail/openstack-dev/2016- > November/107384.html > [2] http://catalyst.net.nz/catalyst-cloud > [3] http://specs.openstack.org/openstack/neutron-specs/specs > /stadium/ocata/neutron-vpnaas.html > ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [Fault Genes] WG Weekly Meeting Summary
Hi All, We had a great meeting today. Following were the items that we discussed: * Zainab presented her word frequency analysis of the Launchpad data and high level review of the source code * Michael provided some info on the types of data in Stackoverflow * Nemat reviewed the updated OpenStack Fault Management Blueprint architecture * Discussed the importance of having SMART logs in OpenStack * Isaac agreed to drive the SMART log sub project in Fault Genes * Ala will be driving the Collector component of the architecture * Zainab will update the chart with the time between failures * Michael will provide the Stackoverflow data in the appropriate format to the team * Zainab will run her word frequency script on the Stackoverflow data * Zainab will merge all word count data into one to be used for dictionary selection * Team will brainstorm on the potential fault classification to be used for the machine learning training data * Suli - provide update on the web based database and Fault Genes front end design Thanks to Isaac for involving more people from his project team in Fault Genes WG. Regards, Nemat ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] What would you like in Pike?
I wanted to let the group know that a study that was conducted by OpenStack UX on behalf of the community. In fact, Tim was one of the participants. https://docs.google.com/presentation/d/1J6-8MwUGGOwy6-A_w1EaQcZQ1Bq2YWeB-kw4vCFxbwM/edit?usp=sharing Cheers, Piet On Thu, Jan 19, 2017 at 12:24 PM, Blair Bethwaite wrote: > 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 wrote: > >> >> On 18 Jan 2017, at 23:20, Matt Jarvis 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 >> 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 >>> 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 >>> 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 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. >
Re: [Openstack-operators] What would you like in Pike?
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 wrote: > > On 18 Jan 2017, at 23:20, Matt Jarvis 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 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 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 >> 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 >>> 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: >>>
Re: [Openstack-operators] [openstack-dev] [keystone] 2017-1-11 policy meeting
Ruan, Good question! I should clarify that there would be no *default* policy file to maintain in the project source code, like in keystone currently [0]. All policy defaults would be coded into the project. Nova has already taken this approach with their policy file [1], which leaves them with nothing to maintain in tree (notice the absence of a sample policy file) [2]. A deployer can still customize policy by using a policy.json file, and those rules are treated as overrides for the defaults in code. [0] https://github.com/openstack/keystone/blob/master/etc/policy.json [1] https://github.com/openstack/nova/blob/master/nova/policies/servers.py [2] https://github.com/openstack/nova/tree/master/etc/nova On Thu, Jan 19, 2017 at 8:35 AM, wrote: > Hi Lance, > > Your option 3 is not clear for me. > > You say that ‘The result would 0 policy files to maintain in tree and > everything would be in code.’ Without this file, how can we define > policies? Can user configure policies? > > Ruan > > > > *From:* Lance Bragstad [mailto:lbrags...@gmail.com] > *Sent:* mercredi 18 janvier 2017 23:16 > *To:* OpenStack Development Mailing List (not for usage questions); > openstack-operators@lists.openstack.org > *Subject:* Re: [openstack-dev] [keystone] 2017-1-11 policy meeting > > > > Looping this into the operator's list, too! > > > > On Wed, Jan 18, 2017 at 2:13 PM, Lance Bragstad > wrote: > > Thanks to Morgan in today's policy meeting [0], we were able to shed some > light on the reasons for keystone having two policy files. The main reason > a second policy file was introduced was to recenter RBAC around concepts > introduced in the V3 API. The problem was that the policy file that came > later [1] wasn't a drop in replacement for the initial one because it > required new roles in order to work properly. Switching to the newer policy > file by default would break deployers who did nothing but implement the > basic RBAC roles required by the initial version [2]. At the time there was > no real way to "migrate" from one policy file to another, so two were > maintained in tree. > > > > Consolidating to a single file, or set of defaults, has benefits for > maintainers and deployers, so we covered paths to accomplish that. We were > able to come up with three paths forward. > >1. Drop support for the original/initial policy file and only maintain >policy.v3cloudsample.json >2. Leverage `keystone-manage bootstrap` to create the new roles >required by policy.v3cloudsample.json >3. Codify the existing policy file using oslo.policy as a vehicle to >introduce new defaults from policy.v3cloudsample.json > > Everyone seemed to agree the 1st option was the most painful for everyone. > Option 2 (and maybe 3) would more than likely require some sort of upgrade > documentation that describes the process. > > > > Without swaying anyone's opinion, I think I tend to lean towards option 3 > because it sounds similar to what nova has done, or is going to do. After > talking to John Garbutt about some of their nova work, it sounded like one > of their next steps was to re-evaluate all RBAC roles/rules now that they > have them in code. If they come across an operation that would benefit from > a different default value, they can use oslo.policy to deprecate or propose > a new default (much like how we use oslo.config for changing or deprecating > configuration values today). From a keystone perspective, this would > effectively mean we would move what we have in policy.json into code, then > do the same exercise with policy.v3cloudsample.json. The result would 0 > policy files to maintain in tree and everything would be in code. From > there - we can work with other projects to standardize on what various > roles mean across OpenStack (hopefully following some sort of guide or > document). > > > > I'm excited to hear what others think of the current options, or if there > is another path forward we missed. > > > > > > [0] http://eavesdrop.openstack.org/meetings/policy/ > 2017/policy.2017-01-18-16.00.log.html > > [1] https://github.com/openstack/keystone/blob/ > 7f2b7e58e74c79e5a09bd5c20e0de9c15d9eabd0/etc/policy.v3cloudsample.json > > [2] https://github.com/openstack/keystone/blob/ > 7f2b7e58e74c79e5a09bd5c20e0de9c15d9eabd0/etc/policy.json > > > > On Wed, Jan 11, 2017 at 11:28 AM, Lance Bragstad > wrote: > > Hey folks, > > > > In case you missed the policy meeting today, we had a good discussion [0] > around incorporating keystone's policy into code using the Nova approach. > > > > Keystone is in a little bit of a unique position since we maintain two > different policy files [1] [2], and there were a lot of questions around > why we have two. This same topic came up in a recent keystone meeting, and > we wanted to loop Henry Nash into the conversation, since I believe he > spearheaded a lot of the original policy.v3cloudsample work. > > > > Let's see if we can air out some of that tribal knowledge and answer a >
Re: [Openstack-operators] [kolla] deprecation/removal of Debian images
We opened the vote to deprecate/remove the Debian support in Kolla: http://lists.openstack.org/pipermail/openstack-dev/2017-January/110466.html Christian. -- Christian Berendt Chief Executive Officer (CEO) Mail: bere...@betacloud-solutions.de Web: https://www.betacloud-solutions.de Betacloud Solutions GmbH Teckstrasse 62 / 70190 Stuttgart / Deutschland Geschäftsführer: Christian Berendt Unternehmenssitz: Stuttgart Amtsgericht: Stuttgart, HRB 756139 ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] What would you like in Pike?
On 18 Jan 2017, at 23:20, Matt Jarvis mailto: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 mailto: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 mailto: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 mailto: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 mailto: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/1hZYCOADJ1gXiFHT1ahwv8-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 suitabilit