Re: [Openstack-operators] Draft Agenda for PAO Ops Meetup (August 18, 19)
Hi all, I've received feedback that maybe there won't be enough HPC folks in Palo Alto to run a 90 minute working session on it :) I would propose to slot in instead one of these three, which are currently not well included on the agenda: 1) apps.openstack.org - What the Ops Community would like from it, should we look from the Application side, ie Applications that can run on your cloud, or Augment your cloud, Products that can help enhance your cloud. 2) Openstack Personas (validation) - The UX team will have a set of roles that we would like to validate with the opertator community. 3) Task Taxonomy - The UX team is creating an inventory of standardized tasks that can be used to create scenarios and create a common vernacular within the community. Any thoughts? Regards, Tom On 03/08/15 18:48, Tom Fifield wrote: Hi all, Registrations are going well for our meetup in Palo Alto. If you're on the fence, hopefully this discussion will get you quickly over the line so you don't miss out! http://www.eventbrite.com/e/openstack-ops-mid-cycle-meetup-tickets-17703258924 So, I've taken our suggestions and attempted to wrangle them into something that would fit in the space we have over 2 days. As a reminder, we have two different kind of sessions - General Sessions, which are discussions for the operator community aimed to produce actions (eg best practices, feedback on badness), and**Working groups**focus on specific topics aiming to make concrete progress on tasks in that area. As always, some stuff has been munged and mangled in an attempt to fit it in. For example, we'd expect to talk about Kolla more generally in the context of Using Containers for Deployment, because there are some other ways to do that too. Similarly, we'd expect the ops project discussion to be rolled into the session on the user committee. Anyway, take a look at the below and reply with your comments! Is anything missing? Something look like a terrible idea? Want to completely change the room layout? There's still a little bit of flexibility at this stage. Tuesday Med II Med III Salon A Salon B Bacchus 9:00 - 10:00Registration 10:00 - 10:30 Introduction 10:30 - 11:15 Burning Issues 11:15 - 11:55 Hypervisor Tuning 11:55 - 12:05 Breakout Explain 12:05 - 13:30 Lunch 13:30 - 15:00 Large Deployments Team Burning Issues Logging WG Upgrades WG Ops Guide Fixing 15:00 - 15:30 Coffee 15:30 - 16:00 Breakout Reports 16:00 - 17:00 Using Containers for Deployment 17:00 - 18:00 Lightening Talks Wednesday Med II Med III Salon A Salon B Bacchus 9:00 - 09:45CMDB: use cases 9:45 - 10:30 Deployment Tips - read only slaves? admin-only API servers? 10:30 - 11:15 What network model are you using? Are you happy? 11:15 - 11:30 Coffee 11:30 - 12:15 User Committee Discussion 12:15 - 12:20 Breakout Explain 12:20 - 13:30 Lunch 13:30 - 15:00 Tools and Monitoring Product WG Packaging HPC Working Group Ops Tags Team 15:00 - 15:30 Coffee 15:30 - 16:00 Breakout Reports 16:00 - 17:00 Feedback Session, Tokyo Planning There will be a followup email shortly regarding moderators for the sessions - thanks to those who volunteered so far! Regards, Tom ___ 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
Re: [Openstack-operators] Neutron IPv6 manual for single-stackinginJuno
On Wed, Aug 05, 2015 at 03:26:24AM EDT, Mike Spreitzer wrote: Sean M. Collins s...@coreitpro.com wrote on 08/04/2015 10:38:26 PM: We have adapted the contents of that wiki page into the networking guide, however I have not seen any work in the Juno release for IPv6 only networking. Brian Haley and I had a talk submission for Tokyo about work that has been done during the Liberty cycle to achieve that. I will bug Brian to submit a patch to the Networking Guide. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. I thank you for your answer and excuse your brevity, but have to ask a follow-up question. You wrote I have not seen any work in the Juno release for IPv6 only networking --- did you mean documentation work or implementation work? I thought there was some support for IPv6 in Juno, enough to enable basic scenarios. I know that dual-stacked routers are not supported in Juno. But can I create a Compute Instance in Juno attached to an IPv6-only tenant network that, in turn, is connected to a router that is attached only to IPv6 networks and a v6-only external network? Sorry for the brevity - what I mean to say is that I don't believe anyone has reported back on that scenario and if it is successful or not. I think Brian and his team has had success, however it is with newer code than Juno? Brian? BTW, have you gotten a fix for the stagefright vulnerability in your Android device? I am really disappointed in my carrier and manufacturer, no sign of any update from them yet. Haven't even heard of it. Uh oh. -- Sean M. Collins ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [app-catalog] IRC Meeting Thursday August 6th at 17:00UTC
Hello! Our next OpenStack App Catalog meeting will take place this Thursday August 6th at 17:00 UTC in #openstack-meeting-3 The agenda can be found here: https://wiki.openstack.org/wiki/Meetings/app-catalog Please add agenda items if there's anything specific you would like to discuss. Please join us if you can! ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Dynamic Policy
As an Op, I've ran into this problem and keep running into it. I would very much like a solution. Its also quite related to the nova instance user issue I've been working on, that's needed by the App Catalog project. So, yes, please keep fighting the good fight. Thanks, Kevin From: Adam Young [ayo...@redhat.com] Sent: Wednesday, August 05, 2015 7:50 AM To: openstack-operators@lists.openstack.org Subject: [Openstack-operators] Dynamic Policy How do you delegate the ability to delegate? Lets say you are running a large cloud (purely hypothetical here) and you want to let a user manage their own project. They are admin but they should be able to invite or eject people. In order to do this, an ordinary user needs to be able to make a role assignment. However, Keystone does not support this today: if you are admin somewhere, you are admin everywhere: https://bugs.launchpad.net/keystone/+bug/968696 Access control in OpenStack is controlled by Policy. An informal survey of operators shows that most people run with the stock policies such as the Nova policy: http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json In order to scope admin to the proejct, we would need to have rules that enforce this scoping: Evey rule should check that the project_id in the token provided matches the project_id of the resource of the API. If we manage to get the policy files rewritten this way, We then need a way to limit what roles a user can assign.The default mechanism would say that a user needs to have an administrative role on the project (or domain) that they want to assign the role on. I don't think anything I've written thus far is controversial. Then, why has it not happened yet? here are the list of problems we need to solve: 1. Operators expect the existing policy files to work as is. Changing them will break workflow. 2. If everything is scoped, we need a way to delete resources left orphan when a project is deleted from Keystone and the service does not get the notification (or know how to handle it). Of the two, I think the top one is the more difficult to solve. Scoping everything can be handled via one of two mechanism; either allow a power-admin user to get a token scoped to some random project (even if it has been deleted) or allow a token scoped to an administrative project to also delete resources for a random project. Dealing with the existing policy file issues is trickier, and that is the real reason for the Dynamic Policy approach: give the endpoints the ability to fetch their policy files from Keystone. If policy goes from being a configuration file to data, it is managed outside of the configuration management tools, and becomes much more fluid. This has risks, and should be an Opt-In mechanism. Fetching the policy files from Keystone also provides the start of a richer set of management for policy rules. Currently, each of the stock policy files exists only in their seperate git repos. There is no sharing of policy rules across projects. If the policy files were managed, rule by rule, from a centralized repository, rules could be shared, providing, among other things, the ability to enforce hierarchical roles, roles namespaced to a service, and other, richer policy management. Feedback on this approach from operators is greatly appreciated. I need to justify the effort that would go in to making this happen, so if you want it, speak up. If, on the other hand, you feel that this is needlessly complicated or would make deployments more difficult, that is important too, and please let me know. Finally, if you can see some alternative methods of implementing a more dynamic access control, please chime in. ___ 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
Re: [Openstack-operators] Dynamic Policy
We ran into this as well. What we did is create an external to keystone api, that we expose to our end users via a UI. The api will let user create projects (with a specific defined quota) and also add users with the project admins role to the project. Those admins can add/remove users from the project and also delete the project. You can also be a member, where you have the ability to spin up vm's under the project but not add/remove users or remove the project. We also do some other stuff to clean up items in a project before its deleted. We are working to move this functionality out of the current external API and into keystone. I believe we were going to look at waffle-haus to add a paste filter to intercept the project create calls and do the needful. We also modified the policy.json files for the services that we care about to add the new roles that we created. Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. On 8/5/15, 9:39 AM, Fox, Kevin M kevin@pnnl.gov wrote: As an Op, I've ran into this problem and keep running into it. I would very much like a solution. Its also quite related to the nova instance user issue I've been working on, that's needed by the App Catalog project. So, yes, please keep fighting the good fight. Thanks, Kevin From: Adam Young [ayo...@redhat.com] Sent: Wednesday, August 05, 2015 7:50 AM To: openstack-operators@lists.openstack.org Subject: [Openstack-operators] Dynamic Policy How do you delegate the ability to delegate? Lets say you are running a large cloud (purely hypothetical here) and you want to let a user manage their own project. They are admin but they should be able to invite or eject people. In order to do this, an ordinary user needs to be able to make a role assignment. However, Keystone does not support this today: if you are admin somewhere, you are admin everywhere: https://bugs.launchpad.net/keystone/+bug/968696 Access control in OpenStack is controlled by Policy. An informal survey of operators shows that most people run with the stock policies such as the Nova policy: http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json In order to scope admin to the proejct, we would need to have rules that enforce this scoping: Evey rule should check that the project_id in the token provided matches the project_id of the resource of the API. If we manage to get the policy files rewritten this way, We then need a way to limit what roles a user can assign.The default mechanism would say that a user needs to have an administrative role on the project (or domain) that they want to assign the role on. I don't think anything I've written thus far is controversial. Then, why has it not happened yet? here are the list of problems we need to solve: 1. Operators expect the existing policy files to work as is. Changing them will break workflow. 2. If everything is scoped, we need a way to delete resources left orphan when a project is deleted from Keystone and the service does not get the notification (or know how to handle it). Of the two, I think the top one is the more difficult to solve. Scoping everything can be handled via one of two mechanism; either allow a power-admin user to get a token scoped to some random project (even if it has been deleted) or allow a token scoped to an administrative project to also delete resources for a random project. Dealing with the existing policy file issues is trickier, and that is the real reason for the Dynamic Policy approach: give the endpoints the ability to fetch their policy files from Keystone. If policy goes from being a configuration file to data, it is managed outside of the configuration management tools, and becomes much more fluid. This has risks, and should be an Opt-In mechanism. Fetching the policy files from Keystone also provides the start of a richer set of management for policy rules. Currently, each of the stock policy files exists only in their seperate git repos. There is no sharing of policy rules across projects. If the policy files were managed, rule by rule, from a centralized repository, rules could be shared, providing, among other things, the ability to enforce hierarchical roles, roles namespaced to a service, and other, richer policy management. Feedback on this approach from operators is greatly appreciated. I need to justify the effort that would go in to making this happen, so if you want it, speak up. If, on the other hand, you feel that this is needlessly complicated or would make deployments more difficult, that is important too, and please let me know. Finally, if you can see some alternative methods of implementing a more dynamic access control, please chime in. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org
Re: [Openstack-operators] Dynamic Policy
On 08/05/2015 12:01 PM, Kris G. Lindgren wrote: We ran into this as well. What we did is create an external to keystone api, that we expose to our end users via a UI. The api will let user create projects (with a specific defined quota) and also add users with the project admins role to the project. Those admins can add/remove users from the project and also delete the project. You can also be a member, where you have the ability to spin up vm's under the project but not add/remove users or remove the project. We also do some other stuff to clean up items in a project before its deleted. We are working to move this functionality out of the current external API and into keystone. I believe we were going to look at waffle-haus to add a paste filter to intercept the project create calls and do the needful. We also modified the policy.json files for the services that we care about to add the new roles that we created. Were you working around limitation by building an external system to Keystone to provide a means of delegating the ability to assign roles? Would you have wanted to synchronize the roles you defined in your Keytone instance with the policy files directly? Did you have to modify policy files beyond the Keystone policy file? Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. On 8/5/15, 9:39 AM, Fox, Kevin M kevin@pnnl.gov wrote: As an Op, I've ran into this problem and keep running into it. I would very much like a solution. Its also quite related to the nova instance user issue I've been working on, that's needed by the App Catalog project. So, yes, please keep fighting the good fight. Thanks, Kevin From: Adam Young [ayo...@redhat.com] Sent: Wednesday, August 05, 2015 7:50 AM To: openstack-operators@lists.openstack.org Subject: [Openstack-operators] Dynamic Policy How do you delegate the ability to delegate? Lets say you are running a large cloud (purely hypothetical here) and you want to let a user manage their own project. They are admin but they should be able to invite or eject people. In order to do this, an ordinary user needs to be able to make a role assignment. However, Keystone does not support this today: if you are admin somewhere, you are admin everywhere: https://bugs.launchpad.net/keystone/+bug/968696 Access control in OpenStack is controlled by Policy. An informal survey of operators shows that most people run with the stock policies such as the Nova policy: http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json In order to scope admin to the proejct, we would need to have rules that enforce this scoping: Evey rule should check that the project_id in the token provided matches the project_id of the resource of the API. If we manage to get the policy files rewritten this way, We then need a way to limit what roles a user can assign.The default mechanism would say that a user needs to have an administrative role on the project (or domain) that they want to assign the role on. I don't think anything I've written thus far is controversial. Then, why has it not happened yet? here are the list of problems we need to solve: 1. Operators expect the existing policy files to work as is. Changing them will break workflow. 2. If everything is scoped, we need a way to delete resources left orphan when a project is deleted from Keystone and the service does not get the notification (or know how to handle it). Of the two, I think the top one is the more difficult to solve. Scoping everything can be handled via one of two mechanism; either allow a power-admin user to get a token scoped to some random project (even if it has been deleted) or allow a token scoped to an administrative project to also delete resources for a random project. Dealing with the existing policy file issues is trickier, and that is the real reason for the Dynamic Policy approach: give the endpoints the ability to fetch their policy files from Keystone. If policy goes from being a configuration file to data, it is managed outside of the configuration management tools, and becomes much more fluid. This has risks, and should be an Opt-In mechanism. Fetching the policy files from Keystone also provides the start of a richer set of management for policy rules. Currently, each of the stock policy files exists only in their seperate git repos. There is no sharing of policy rules across projects. If the policy files were managed, rule by rule, from a centralized repository, rules could be shared, providing, among other things, the ability to enforce hierarchical roles, roles namespaced to a service, and other, richer policy management. Feedback on this approach from operators is greatly appreciated. I need to justify the effort that would go in to making this happen, so if you want it, speak up. If, on the other hand, you feel that this is needlessly
[Openstack-operators] [hpc] Tuning KVM
FYI, a few suggestions on tuning CPU bound workloads with KVM at http://openstack-in-production.blogspot.fr/2015/08/kvm-and-hyper-v-comparison-for-high.html. The Kilo enhancements looks to be a great help. Tim ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
[Openstack-operators] [neutron] Any users of Neutron's VPN advanced service?
Operators: We (myself, Paul and Doug) are looking to better understand who might be using Neutron's VPNaaS code. We're looking for what version you're using, how long you're using it, and if you plan to continue deploying it with future upgrades. Any information operators can provide here would be fantastic! Thank you! Kyle ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [neutron] Any users of Neutron's VPN advanced service?
I attempted to run it in Juno a while back and had very little success. I would love to be able to use it though, and will give it another shot once upgraded to Kilo. My issue was that several of the options coded into it for firing up a connection were specific to Freeswan which was deprecated, at least in CentOS 7, in favor of Libreswan. Even after hacking in the changes, it still failed to start due to some locking or permissions issue that I could never resolve. Given that we run isolated tenant networks with overlapping IP space for a number of enterprise customers, having a working self-service VPN would be great to have, and I'm looking forward to some future success with it. -Erik On Wed, Aug 5, 2015 at 3:56 PM, Kyle Mestery mest...@mestery.com wrote: Operators: We (myself, Paul and Doug) are looking to better understand who might be using Neutron's VPNaaS code. We're looking for what version you're using, how long you're using it, and if you plan to continue deploying it with future upgrades. Any information operators can provide here would be fantastic! Thank you! Kyle ___ 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
Re: [Openstack-operators] Dynamic Policy
Echoing what others have said, we too have an abstraction layer in the form of a custom UI to allow project owners to create/delete users. As for your questions Adam, having policy in the Keystone database as data seems like a no brainer. As you suggest it enables us to do so much more. For problem #2, that's already a problem today, so I don't see how it has an impact (other than the problem of giving the keys to end-users). In fact, I'd argue that it's an even bigger problem today as an admin (i.e admin everywhere) can delete a project with running resources. A project_admin role limited in scope could be delegated the rights to create/delete users but not projects. -m On Wed, 2015-08-05 at 18:15 +, Kris G. Lindgren wrote: See inline. Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. On 8/5/15, 11:19 AM, Adam Young ayo...@redhat.com wrote: On 08/05/2015 12:01 PM, Kris G. Lindgren wrote: We ran into this as well. What we did is create an external to keystone api, that we expose to our end users via a UI. The api will let user create projects (with a specific defined quota) and also add users with the project admins role to the project. Those admins can add/remove users from the project and also delete the project. You can also be a member, where you have the ability to spin up vm's under the project but not add/remove users or remove the project. We also do some other stuff to clean up items in a project before its deleted. We are working to move this functionality out of the current external API and into keystone. I believe we were going to look at waffle-haus to add a paste filter to intercept the project create calls and do the needful. We also modified the policy.json files for the services that we care about to add the new roles that we created. Were you working around limitation by building an external system to Keystone to provide a means of delegating the ability to assign roles? Yes. Basically we wrapped a function that required admin permissions in an keystone API - so that non-admin users could do some admin level tasks. Also, we have ran into the admin on a project in keystone == admin everywhere problem. We were using a created project_admin role to get around that limitation. Would you have wanted to synchronize the roles you defined in your Keytone instance with the policy files directly? Did you have to modify policy files beyond the Keystone policy file? Yes. And Yes, we did modify other services policy files as well to handle the newly created project_admin role. Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. On 8/5/15, 9:39 AM, Fox, Kevin M kevin@pnnl.gov wrote: As an Op, I've ran into this problem and keep running into it. I would very much like a solution. Its also quite related to the nova instance user issue I've been working on, that's needed by the App Catalog project. So, yes, please keep fighting the good fight. Thanks, Kevin From: Adam Young [ayo...@redhat.com] Sent: Wednesday, August 05, 2015 7:50 AM To: openstack-operators@lists.openstack.org Subject: [Openstack-operators] Dynamic Policy How do you delegate the ability to delegate? Lets say you are running a large cloud (purely hypothetical here) and you want to let a user manage their own project. They are admin but they should be able to invite or eject people. In order to do this, an ordinary user needs to be able to make a role assignment. However, Keystone does not support this today: if you are admin somewhere, you are admin everywhere: https://bugs.launchpad.net/keystone/+bug/968696 Access control in OpenStack is controlled by Policy. An informal survey of operators shows that most people run with the stock policies such as the Nova policy: http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json In order to scope admin to the proejct, we would need to have rules that enforce this scoping: Evey rule should check that the project_id in the token provided matches the project_id of the resource of the API. If we manage to get the policy files rewritten this way, We then need a way to limit what roles a user can assign.The default mechanism would say that a user needs to have an administrative role on the project (or domain) that they want to assign the role on. I don't think anything I've written thus far is controversial. Then, why has it not happened yet? here are the list of problems we need to solve: 1. Operators expect the existing policy files to work as is. Changing them will break workflow. 2. If everything is scoped, we need a way to delete resources left orphan when a project is deleted from Keystone and the
Re: [Openstack-operators] Draft Agenda for PAO Ops Meetup (August 18, 19)
Thanks Geoff. Which session would you propose to replace? Regards, Tom On 06/08/15 03:14, Geoff Arnold wrote: I’d like to see some time spent on specific issues associated with public cloud operations. (This is not the same as Large Deployments.) As Stefano pointed out yesterday: http://maffulli.net/2015/08/04/a-new-push-for-openstack-public-clouds/ this is an area which probably needs more attention. Cheers, Geoff On Aug 4, 2015, at 11:11 PM, Tom Fifield t...@openstack.org mailto:t...@openstack.org wrote: Hi all, I've received feedback that maybe there won't be enough HPC folks in Palo Alto to run a 90 minute working session on it :) I would propose to slot in instead one of these three, which are currently not well included on the agenda: 1)apps.openstack.org http://apps.openstack.org/-What the Ops Community would like from it, should we look from the Application side, ie Applications that can run on your cloud, or Augment your cloud, Products that can help enhance your cloud. 2) Openstack Personas (validation) - The UX team will have a set of roles that we would like to validate with the opertator community. 3) Task Taxonomy - The UX team is creating an inventory of standardized tasks that can be used to create scenarios and create a common vernacular within the community. Any thoughts? Regards, Tom On 03/08/15 18:48, Tom Fifield wrote: Hi all, Registrations are going well for our meetup in Palo Alto. If you're on the fence, hopefully this discussion will get you quickly over the line so you don't miss out! http://www.eventbrite.com/e/openstack-ops-mid-cycle-meetup-tickets-17703258924 So, I've taken our suggestions and attempted to wrangle them into something that would fit in the space we have over 2 days. As a reminder, we have two different kind of sessions - General Sessions, whichare discussions for the operator community aimed to produce actions (eg best practices, feedback on badness), and**Working groups**focus on specific topicsaiming to make concrete progress on tasks in that area. As always, some stuff has been munged and mangled in an attempt to fit it in. For example, we'd expect to talk about Kolla more generally in the context of Using Containers for Deployment, because there are some other ways to do that too. Similarly, we'd expect the ops project discussion to be rolled into the session on the user committee. Anyway, take a look at the below and reply with your comments! Is anything missing? Something look like a terrible idea? Want to completely change the room layout? There's still a little bit of flexibility at this stage. Tuesday Med II Med III Salon A Salon B Bacchus 9:00 - 10:00Registration 10:00 - 10:30 Introduction 10:30 - 11:15 Burning Issues 11:15 - 11:55 Hypervisor Tuning 11:55 - 12:05 Breakout Explain 12:05 - 13:30 Lunch 13:30 - 15:00 Large Deployments Team Burning Issues Logging WG Upgrades WG Ops Guide Fixing 15:00 - 15:30 Coffee 15:30 - 16:00 Breakout Reports 16:00 - 17:00 Using Containers for Deployment 17:00 - 18:00 Lightening Talks Wednesday Med II Med III Salon A Salon B Bacchus 9:00 - 09:45CMDB: use cases 9:45 - 10:30Deployment Tips - read only slaves? admin-only API servers? 10:30 - 11:15 What network model are you using? Are you happy? 11:15 - 11:30 Coffee 11:30 - 12:15 User Committee Discussion 12:15 - 12:20 Breakout Explain 12:20 - 13:30 Lunch 13:30 - 15:00 Tools and MonitoringProduct WG Packaging HPC Working Group Ops Tags Team 15:00 - 15:30 Coffee 15:30 - 16:00 Breakout Reports 16:00 - 17:00 Feedback Session, Tokyo Planning There will be a followup email shortly regarding moderators for the sessions - thanks to those who volunteered so far! Regards, Tom ___ 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 mailto:OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Dynamic Policy
Jumping in with another us too here. We have some custom Horizon extensions that allow project owners to manage some of this stuff. On Wed, Aug 5, 2015 at 4:14 PM, Marc Heckmann marc.heckm...@ubisoft.com wrote: Echoing what others have said, we too have an abstraction layer in the form of a custom UI to allow project owners to create/delete users. As for your questions Adam, having policy in the Keystone database as data seems like a no brainer. As you suggest it enables us to do so much more. For problem #2, that's already a problem today, so I don't see how it has an impact (other than the problem of giving the keys to end-users). In fact, I'd argue that it's an even bigger problem today as an admin (i.e admin everywhere) can delete a project with running resources. A project_admin role limited in scope could be delegated the rights to create/delete users but not projects. -m On Wed, 2015-08-05 at 18:15 +, Kris G. Lindgren wrote: See inline. Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. On 8/5/15, 11:19 AM, Adam Young ayo...@redhat.com wrote: On 08/05/2015 12:01 PM, Kris G. Lindgren wrote: We ran into this as well. What we did is create an external to keystone api, that we expose to our end users via a UI. The api will let user create projects (with a specific defined quota) and also add users with the project admins role to the project. Those admins can add/remove users from the project and also delete the project. You can also be a member, where you have the ability to spin up vm's under the project but not add/remove users or remove the project. We also do some other stuff to clean up items in a project before its deleted. We are working to move this functionality out of the current external API and into keystone. I believe we were going to look at waffle-haus to add a paste filter to intercept the project create calls and do the needful. We also modified the policy.json files for the services that we care about to add the new roles that we created. Were you working around limitation by building an external system to Keystone to provide a means of delegating the ability to assign roles? Yes. Basically we wrapped a function that required admin permissions in an keystone API - so that non-admin users could do some admin level tasks. Also, we have ran into the admin on a project in keystone == admin everywhere problem. We were using a created project_admin role to get around that limitation. Would you have wanted to synchronize the roles you defined in your Keytone instance with the policy files directly? Did you have to modify policy files beyond the Keystone policy file? Yes. And Yes, we did modify other services policy files as well to handle the newly created project_admin role. Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. On 8/5/15, 9:39 AM, Fox, Kevin M kevin@pnnl.gov wrote: As an Op, I've ran into this problem and keep running into it. I would very much like a solution. Its also quite related to the nova instance user issue I've been working on, that's needed by the App Catalog project. So, yes, please keep fighting the good fight. Thanks, Kevin From: Adam Young [ayo...@redhat.com] Sent: Wednesday, August 05, 2015 7:50 AM To: openstack-operators@lists.openstack.org Subject: [Openstack-operators] Dynamic Policy How do you delegate the ability to delegate? Lets say you are running a large cloud (purely hypothetical here) and you want to let a user manage their own project. They are admin but they should be able to invite or eject people. In order to do this, an ordinary user needs to be able to make a role assignment. However, Keystone does not support this today: if you are admin somewhere, you are admin everywhere: https://bugs.launchpad.net/keystone/+bug/968696 Access control in OpenStack is controlled by Policy. An informal survey of operators shows that most people run with the stock policies such as the Nova policy: http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json In order to scope admin to the proejct, we would need to have rules that enforce this scoping: Evey rule should check that the project_id in the token provided matches the project_id of the resource of the API. If we manage to get the policy files rewritten this way, We then need a way to limit what roles a user can assign.The default mechanism would say that a user needs to have an administrative role on the project (or domain) that they want to assign the role on. I don't think anything I've written thus far
Re: [Openstack-operators] Dynamic Policy
On 06/08/15 04:01, Kris G. Lindgren wrote: We ran into this as well. What we did is create an external to keystone api, that we expose to our end users via a UI. The api will let user create projects (with a specific defined quota) and also add users with the project admins role to the project. Those admins can add/remove users from the project and also delete the project. You can also be a member, where you have the ability to spin up vm's under the project but not add/remove users or remove the project. We also do some other stuff to clean up items in a project before its deleted. We are working to move this functionality out of the current external API and into keystone. I believe we were going to look at waffle-haus to add a paste filter to intercept the project create calls and do the needful. We're working on something similar, but haven't rolled it to production yet. Is your code available open-source somewhere? Ours will be once it's clean-ish and tested properly, but not yet lest we lead someone into pain and misery. One of the goals you didn't mention above, but I'm sure you also noted, was that changing passwords or setting an initial password isn't exactly clear - we're working on getting a one time link set that an initial user can be sent to be able to set their own first password. We also modified the policy.json files for the services that we care about to add the new roles that we created. Not the easiest task to either get right, or make sure that the files are distributed around in an HA setting. But absolutely necessary. Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
