Re: [Openstack-operators] [neutron] Any users of Neutron's VPN advanced service?

[Edgar Magana]

I know I can’t wear both hats but in this case as Operator as one of the 
constant moderators for the neutron-related sessions, I can say that I have 
never received a report about the VPNaaS code from the Operators. This could be 
means two things, the code is terrific and nobody has issues with it or 
basically nobody uses it.

Thanks,

Edgar


From: Kyle Mestery
Date: Wednesday, August 5, 2015 at 12:56 PM
To: 
"openstack-operators@lists.openstack.org"
Cc: Paul Michali, Doug Wiegley
Subject: [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] Draft Agenda for PAO Ops Meetup (August 18, 19)

[Tom Fifield]

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 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 -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

http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators





_

Re: [Openstack-operators] Dynamic Policy

[Matt Fischer]

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 
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"  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"  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 

[Openstack-operators] Opportunity for a Ceph expert

[Adam Lawson]

I'm reaching out to the community here in hopes there's someone with deep
understanding of (and preferably support experience with) Ceph reading
this. If that's you, can you please email me offline ASAP? I want to talk
to you (whoever you may be) for a quick/lucrative remote consulting
opportunity. US/EU-based individuals with excellent English only please.
Thanks!

/adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Dynamic Policy

[Xav Paice]

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

[Openstack-operators] [neutron] Any users of Neutron's VPN advanced service?

[Tamanna Z Sait]

Hi Kyle

We have been actively using Neutron VPNaaS code from icehouse, juno, kilo 
releases and have plans to upstream bug fixes as well as enhancements in 
this neurton's VPNaaS area moving forward. 
We have been using the feature for over 1 year now and plan to continue to 
use it and deploy it.



Kyle Mestery mestery at mestery.com 
Wed Aug 5 19:56:01 UTC 2015 
Previous message: [Openstack-operators] [hpc] Tuning KVM 
Next message: [Openstack-operators] [neutron] Any users of Neutron's VPN 
advanced service? 
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 

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
-- next part --
An HTML attachment was scrubbed...
URL: <
http://lists.openstack.org/pipermail/openstack-operators/attachments/20150805/e38465b2/attachment.html
>




___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Dynamic Policy

[Marc Heckmann]

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"  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"  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,
> 

Re: [Openstack-operators] [neutron] Any users of Neutron's VPN advanced service?

[Erik McCormick]

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  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

[Openstack-operators] [neutron] Any users of Neutron's VPN advanced service?

[Kyle Mestery]

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] Dynamic Policy

[Geoff Arnold]

I suspect that if we audited all OpenStack deployments we’d find that an awful 
lot of them have built something similar. (In our case we re-used the Cisco 
Prime Service Catalog system, but that was just a matter of convenience.) It 
would be nice if we could minimize the need for this, but many of us will need 
a framework that allows us to integrate some identity and BSS workflows.

Geoff

> On Aug 5, 2015, at 9:01 AM, 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.
> 
> 
> Kris Lindgren
> Senior Linux Systems Engineer
> GoDaddy, LLC.
> 
> 
> 
> 
> On 8/5/15, 9:39 AM, "Fox, Kevin M"  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 

Re: [Openstack-operators] [hpc] Tuning KVM

[Matt Joyce]

Definitely worth the read.

On August 5, 2015 3:22:33 PM EDT, Tim Bell  wrote:
>
>They are  workload specific so it is more a suggestion of where to look
>at optimising rather than a unique HTC profile for any application. 
>So, try them out with your workload and choose which ones make sense.
>
>We'll be working with upstream so that the cloud consumer can choose
>the right options where possible for their workload. Clearly, some have
>impacts for the hypervisor too but it is good to find the right balance
>between consumers wanting maximum performance and providers wanting
>reasonable isolation and correct resource allocation.
>
>Tim
>
>> -Original Message-
>> From: Antonio Messina [mailto:antonio.mess...@uzh.ch]
>> Sent: 05 August 2015 21:15
>> To: Tim Bell 
>> Cc: openstack-operators@lists.openstack.org
>> Subject: Re: [Openstack-operators] [hpc] Tuning KVM
>> 
>> Hi Tim, thank you for sharing!
>> Those blog posts are very interesting!
>> 
>> cheers
>> .a.
>> 
>> 
>> On Wed, Aug 5, 2015 at 8:56 PM, Tim Bell  wrote:
>> >
>> >
>> > 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-operator
>> > s
>> >
>> 
>> 
>> 
>> --
>> antonio.mess...@uzh.ch
>> S3IT: Services and Support for Science IT   
>http://www.s3it.uzh.ch/
>> University of Zurich Y12 F 84
>> Winterthurerstrasse 190
>> CH-8057 Zurich Switzerland
>___
>OpenStack-operators mailing list
>OpenStack-operators@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [hpc] Tuning KVM

[Tim Bell]

They are  workload specific so it is more a suggestion of where to look at 
optimising rather than a unique HTC profile for any application.  So, try them 
out with your workload and choose which ones make sense.

We'll be working with upstream so that the cloud consumer can choose the right 
options where possible for their workload. Clearly, some have impacts for the 
hypervisor too but it is good to find the right balance between consumers 
wanting maximum performance and providers wanting reasonable isolation and 
correct resource allocation.

Tim

> -Original Message-
> From: Antonio Messina [mailto:antonio.mess...@uzh.ch]
> Sent: 05 August 2015 21:15
> To: Tim Bell 
> Cc: openstack-operators@lists.openstack.org
> Subject: Re: [Openstack-operators] [hpc] Tuning KVM
> 
> Hi Tim, thank you for sharing!
> Those blog posts are very interesting!
> 
> cheers
> .a.
> 
> 
> On Wed, Aug 5, 2015 at 8:56 PM, Tim Bell  wrote:
> >
> >
> > 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-operator
> > s
> >
> 
> 
> 
> --
> antonio.mess...@uzh.ch
> S3IT: Services and Support for Science IThttp://www.s3it.uzh.ch/
> University of Zurich Y12 F 84
> Winterthurerstrasse 190
> CH-8057 Zurich Switzerland
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] Draft Agenda for PAO Ops Meetup (August 18, 19)

[Geoff Arnold]

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  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  - 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:00 Registration
>> 
>> 
>> 
>> 10:00 - 10:30Introduction
>> 
>> 
>> 
>> 10:30 - 11:15Burning Issues  
>> 
>> 
>> 
>> 11:15 - 11:55Hypervisor Tuning   
>> 
>> 
>> 
>> 11:55 - 12:05Breakout Explain
>> 
>> 
>> 
>> 12:05 - 13:30Lunch   
>> 
>> 
>> 
>> 13:30 - 15:00Large Deployments Team  Burning Issues  Logging WG  
>> Upgrades WG Ops Guide Fixing
>> 15:00 - 15:30Coffee  
>> 
>> 
>> 
>> 15:30 - 16:00Breakout Reports
>> 
>> 
>> 
>> 16:00 - 17:00Using Containers for Deployment 
>> 
>> 
>> 
>> 17:00 - 18:00Lightening Talks
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> WednesdayMed II  Med III Salon A Salon B Bacchus
>> 9:00 - 09:45 CMDB: use cases 
>> 
>> 
>> 
>> 9:45 - 10:30 Deployment Tips - read only slaves? admin-only API servers? 
>> 
>> 
>> 
>> 10:30 - 11:15What network model are you using? Are you happy?
>> 
>> 
>> 
>> 11:15 - 11:30Coffee  
>> 
>> 
>> 
>> 11:30 - 12:15User Committee Discussion   
>> 
>> 
>> 
>> 12:15 - 12:20Breakout Explain
>> 
>> 
>> 
>> 12:20 - 13:30Lunch   
>> 
>> 
>> 
>> 13:30 - 15:00Tools and MonitoringProduct WG  Packaging   
>> HPC Working Group   Ops Tags Team
>> 15:00 - 15:30Coffee  
>> 
>> 
>> 
>> 15:30 - 16:00Breakout Reports
>> 
>> 
>> 
>> 16:00 - 17:00Feedback 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 
> 

[Openstack-operators] [hpc] Tuning KVM

[Tim Bell]

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

Re: [Openstack-operators] Dynamic Policy

[Kris G. Lindgren]

See inline.

 
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy, LLC.



On 8/5/15, 11:19 AM, "Adam Young"  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"  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 

Re: [Openstack-operators] Dynamic Policy

[Curtis]

On Wed, Aug 5, 2015 at 10:01 AM, 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.

waffle-haus...that sounds really interesting. (Presuming it's this
repo: https://github.com/roaet/wafflehaus ). Will have to look into
that, thanks!

>
> 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"  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 n

Re: [Openstack-operators] Dynamic Policy

[Adam Young]

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"  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 complicate

Re: [Openstack-operators] Dynamic Policy

[Kris G. Lindgren]

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"  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

Re: [Openstack-operators] Dynamic Policy

[Fox, Kevin M]

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

[matt]

Adam.


The second issue is a big one.  I think a lot of operators ( especially
newer operators ) are not aware of how much cruft builds up in the database
over time from left over security policies as tenants are created and
removed.  It causes issues.  I've had to work on software to manually clean
out those leftovers before.  This is a really nasty problem to solve for, I
am aware.  But it is a problem that flies under the radar for a lot of
users until it bites them in the ass.  I'd love to see some more focus on
solving for this.  It's just good house keeping.

In general when we look to dynamic policies and federation I keep hoping
for a day when we can deploy openstack environments in small scale
horizontally.  3000 node openstack environments are an absurd request.  The
problems inherent in scaling the network alone to say nothing of the
rabbitmq environment are non-trivial.  If we could stand up 8-16 rack
openstack environments and just scale those environments horizontally as
needed, tying them back into the whole seemlessly... I'd be a happy happy
operator.

I am not sure if that helps provide some perspective on your question.
But, I thought it was worth noting.

Thanks for asking and being awesome as always!  You rock!

-matt



On Wed, Aug 5, 2015 at 10:50 AM, Adam Young  wrote:

> 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 

[Openstack-operators] Dynamic Policy

[Adam Young]

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] [app-catalog] IRC Meeting Thursday August 6th at 17:00UTC

[Christopher Aedo]

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] Neutron IPv6 manual for single-stackinginJuno

[Sean M. Collins]

On Wed, Aug 05, 2015 at 03:26:24AM EDT, Mike Spreitzer wrote:
> "Sean M. Collins"  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

Re: [Openstack-operators] Neutron IPv6 manual for single-stackinginJuno

[Mike Spreitzer]

"Sean M. Collins"  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?

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.

Thanks,
Mike

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators